Arpit's Newsletter read by 56000+ engineers
Weekly essays on real-world system design, distributed systems, or a deep dive into some super-clever algorithm.
We all love creating microservices, but there should be a standard way of creating them?
If we give complete autonomy to engineers to build their services then we will end up with the chaos of languages, frameworks, tools, and conventions. Hence standardization becomes essential to limit the chaos.
Standardization allows us to keep the entire system coherent and uniform and the 3 verticals that need standardization are:
Monitoring one microservice is relatively a simpler problem, and with easy-to-integrate tools, it becomes a breeze. Few examples
Monitoring how a request originates from the user and goes through various services is important and this problem of Distributed Tracing can be solved through tools like Zipkin and AWS X-Ray.
Microservices need a standard way of reporting key metrics like CPU, Memory, Disk, and App Metrics into a central system like NewRelic or CloudWatch allowing everyone to get the necessary transparency.
There are 100s of ways through which the microservices could talk to each other. This demands standardization and we need to consolidate on a few ways of interfacing.
Consolidating to REST for user-to-service communication and gRPC for service-to-service communication seems to be the most popular choices. But it is totally up to you to pick the ones.
We cannot allow the communication to happen over a variety of formats and hence we need to consolidate on a few like - JSON and ProtoBuf.
We also need to standardize the nomenclature and how REST endpoints are written. This would ensure that the entire engineering team feels familiar while writing any inter-service communication.
Other aspects that need standardization are Versioning, Timeouts, and Retries. Having this standardization would allow us to write common libraries to abstract out the implementation complexities and save redundant efforts.
Every service needs to shield itself from getting bombarded. Standardizing the tolerance would save us redundant efforts and implementations. A common protection layer would not only prevent the service from getting overwhelmed but also ensure no cascading failures.
Some standard configurations could be
Such abilities would help us reduce outage times and prevent cascading failures as engineers would be aware of exactly what to do to cut off.
Here's the video ⤵
Super practical courses, with a no-nonsense approach, are designed to spark engineering curiosity and help you ace your career.
An in-depth, self-paced, and on-demand course that for early engineers to become great at designing scalable, available, and extensible systems at scale.
A masterclass that helps experienced engineers become great at designing scalable, fault-tolerant, and highly available systems.
A course that helps covers Redis internals by reimplementing its core features like - event loop, serialization protocol, pipelining, eviction, and transactions.
Arpit's Newsletter read by 56000+ engineers
Weekly essays on real-world system design, distributed systems, or a deep dive into some super-clever algorithm.