Resilient Is Futile

• 

  Type of aurora serverless spin up

• 

  distribute length of query with respective clusters

• 

  scale back down

• 

  distribute and transact

• 

  failure on main db

• 

  stack on normal days

Inspiration

I have problem with persisting db when it's unpredictable spiky at prod, db tends to be slow at hot times and when you are rushing your reports and needing of extra boost to clear through your DLQ.

What it does

The current design is specifically imitate a failure of db causing all the transaction to halt and unable to provide further queue to finish. The design of having secondary fleet of aurora serverless will provide the speed/capacity on demand to persist queues at cost efficient savings.

How I built it

First i draw my use case and put my thought to work and eventually working part by part.

Challenges I ran into

Coding the lambda function and working my way with aurora db with cli

Accomplishments that I'm proud of

Designing the use case.

What I learned

AWS aurora db serverless is very cool, AWS kinesis firehose is fast

What's next for Resilient Is Futile

I think implementation of full aurora serverless stack to replace the non serverless design and also implement smart scaling on the serverless aurora db.

Built With

• amazon-web-services