I remember the first time I played around with Read Replicas. It boosted the overall performance of the app since we had many read requests and a few write requests.
The Read Load replicas is pattern not so difficult to put in place.
It's very easy to setup a Aurora database and start writing and reading. However, when the load starts to be high the problems come.
I would recommend to setup the Read Load replicas from the beginning because it's not so expensive and your system will be able to scale from the minute zero.
What is required in realtime should by synchronous
and everything else should be asynchronous.
The first method which involves publisher and subscriber is more of an async approach to process the data where the caller is not waiting for any response.
The second method to increase more read replicas is certainly a great way to increase read throughput of the system.
Another horizontal scaling strategy (in event driven systems) could be to have separate read and write models abstracted away within separate services; this is typical of CQRS based systems.
Nicely explained Raul.
Competing consumer patterns is quite interesting.
Also, thanks for the mention!
One of my favorites, Saurabh.
Thanks!
I remember the first time I played around with Read Replicas. It boosted the overall performance of the app since we had many read requests and a few write requests.
Thank you for the mention, Raul! 🙏
They offer a good ROI!
Thanks, Petar.
The Read Load replicas is pattern not so difficult to put in place.
It's very easy to setup a Aurora database and start writing and reading. However, when the load starts to be high the problems come.
I would recommend to setup the Read Load replicas from the beginning because it's not so expensive and your system will be able to scale from the minute zero.
Good article Raúl!
Aurora definitively help. Replication is simple to setup and we don't need to pay for the extra storage.
Thanks for adding, Marcos!
competing consumer pattern looks interesting, nice article.
Indeed it is.
Thanks, Neo!
I guess another way to put this is:
What is required in realtime should by synchronous
and everything else should be asynchronous.
The first method which involves publisher and subscriber is more of an async approach to process the data where the caller is not waiting for any response.
The second method to increase more read replicas is certainly a great way to increase read throughput of the system.
Well put, Raul. 🙌
Another horizontal scaling strategy (in event driven systems) could be to have separate read and write models abstracted away within separate services; this is typical of CQRS based systems.