Irwan Hendra's Random Codes Blog

 Context: Services request timeout is usually something that is less scrutinized over when designing a solution. Which is rightly so if we are considering a simple solutons (1-2 daisy chained microservices), and/or monolith ones. However that changes when we start looking at 5+ daisy chained microservices, as the diagram below illustrate it Fig 1. All microservices have the same timeouts Now one could argue that we could obtain baseline of how long on average Microservice 5 will take to process the request and generate a response and configure each of the microservices accordingly, such as follow: Fig 2. Each microservices slightly higher timeouts than downstream Which indeed would work well under a straight forward, theoritical happy case scenario. However most experienced SREs would agree that what matter is not the happy case scenario, but how the system handle all sort of stress loads. Even if we can come up with the golden number for the baseline of Microservice 5, this approa...

Context You have a document database, let's say DynamoDB. It has about 10m of person's name data, for example:  The data is accessible through a highly scalable API and being consumed by 100+ other services. Over the course of few years there are some significant changes that require several iterations of the data and API, but all versions have to be maintained due to various legacy clients. The iterations are summarised as follow: V2: Suffixes are now mandatory V3: Title is now forbidden V4: Givenname to change to Firstname V5: Tony Stark Jr is now the supreme leader of earth, all Stark lastname must be capitalised Forces You only have one Document DB All versions must be maintained Solution V2: Suffixes are now mandatory Adding a new field is quite straight forward, we simply add to the Document DB V1: leave it unchanged or update it to make sure that it does not return Suffix V3: Title is now forbidden Removing a field is trickier, since we have to maintain backward compatib...