Meng Lin's Byte-Wise Words

  👀 If you've been intrigued by the headline about the Prime Video team reducing their cloud spending by 90% after moving from a distributed microservices architecture to a monolithic application, it's worth taking a closer look before jumping to conclusions.💡 To start with, there is no such thing as a “perfect architecture design”, any battle-tested architecture design is a compromise of many considerations for its given situation. It's easy for monolithic supporters to overlook the significant benefits that serverless architecture can bring, just as serverless advocates can gloss over the trade-offs and penalties that come with it, known as the "fallacies of distributed computing." More importantly, "Serverless First" approach doesn't mean "Serverless Only", microservices are not the only answer to everything, don’t let serverless be that only sledgehammer in your toolbox. Architecture design is a complex decision-making process and is...

Intent  When moving to microservices architecture, one of the biggest challenges is dealing with data consistency among a swarm of microservices. Microservices are loosely coupled and separated by bounded contexts, such as a transaction through the trade lifecycle, which needs to be broken into local atomic transactions that can be executed by individual microservices within their own domain (not the other way around, i.e. a microservice knowing the internal constructs of other microservices’ databases). In order to achieve eventual consistency within a business transaction , the microservices need to be able to: persist data in relation to their own domain, and  publish events to the event broker upon changes to asynchronously trigger the execution of other processing units. These are two distinct operations, often referred to as dual write . Because they are two separate operations of an atomic transaction, it became a source of consistency issues, performance dips and scal...

Intent Modern services are designed to be stateless, meaning a server processes requests only based on the information provided without having to rely on information from earlier requests. This is the ideal scenario but real-life processing flows do not always comply with that principle, such as: There are more than one processing server available to process an event flow that relies on the knowledge of previous executions; Scaling up server instances amid processing of large volumes of events; Use of sharding architecture; All this requires a stateful approach to routing so that the API calls and events  contain sufficient data with each request to ensure proper routing and application behaviour. This is required to maintain the lineage of the flow to prevent: accidental loss of information; or worse,  race conditions due to the events being processed in the wrong order by different instances of service.  Following are some approaches for mitigation. Sticky Session Load ...