I am trying to have a better understanding of a few things in microservices design and architecture and looking for a great and near concrete example.
Let's say we own an online store, like Amazon. We have a big catalog of products.
This would be a catalog service. It would also hold it's own database.
But, to improve performance and make it scale due to demand, holding, for example, millions and millions of records is not great and will suffer severe perf issues for those millions and billions of requests coming through from the API gateway from users who want to search for products.
So, what is the best way to:
- improve perf (besides the correct indexing etc...)
- improve scalability
- make it distributable
I would want to cache some of the MFU data with a LRU eviction but the cache will grow and there may eventually be a limit?
Does it make sense to "split" the data and have it ordered? Example have a "partition" of products that begin with A or B or C etc...? If so, then what is the technical term?
What would be a scalable DB system to use in this case?
What about doing a regional fail over? We have to replicate the data as soon as the products are added to the catalog to ensure we have the data, by potentially using some form of event hub and subscribers listening for those pushes to then push the data into the DB?
Also how would one actually make it scalable?
What about the load? I know we would need to place LB's (Load balancers) in place which would mean that we would have to have some kind of DB copies for the LB to be able to pick the DB that has less load? Or am I thinking incorrectly?
I am thinking about everything in perspective from perf, reliability, resiliency abd
Let's use Azure as a platform if we are wanting to relate to a particular cloud platform.
question from:
https://stackoverflow.com/questions/65713415/microservices-and-data-design-decisions-for-reliability-and-performance 与恶龙缠斗过久,自身亦成为恶龙；凝视深渊过久,深渊将回以凝视…
