There are a lot of recommendations floating around for how to build systems. Some of the example include follow domain-driven design and build stateless application servers. No recommendation is good or bad, any every choice has a trade-offs. Today’s blog covers some of the guidelines or suggestions for designing better and useful systems.
Assume you’ve to build a payments application supporting multiple payment options such as UPI, credit card. Each of these payment option state is synced using callbacks and synchronous APIs with the payment providers.
Guideline of Isolation: Build it Modularly
The system should be built as modules with each module being independent on its own. This helps with maintainability and reusability of modules.
Example includes keeping independent modules for different payment methods and separate module for callback processing. You can keep the common stuff in common module which can be imported as needed.
Guideline of Simplicity: Keep it Simple, Silly
You should always avoid unnecessary components. Only build what’s really needed. Iterate over the implementation - always test and improve.
Examples include trying to support a lot of payment methods in the beginning or thinking of going global on day zero. This could create extra churn and gets the project delayed.
** The NOTES in this blog are taken from Chapter 01 of System Design on AWS. Explore the book:
📕 O’Reilly: https://oreil.ly/ruQbc
📕 Amazon.in: https://amzn.to/4jExkte
📕 Amazon.com: https://amzn.to/3D3BIBJ
Guideline of Performance: Metrics Don’t Lie
Metrics (observability) are really important. They helps in debugging as well as how well your system is doing.
Example metrics include time taken for payment processing and payment failure rates.
Guideline of Trade-offs: There is no such thing as Free Lunch
Every choice has trade-offs. There are pros and cons with every approach. Choose what makes sense for your business use case and to your product’s scale. Take inspiration from others but don’t follow blindly.
Example, thinking of independent micro-services from day one because you can scale them independently. Well yes, but who will manage this?
Guideline of Use-cases: It Always Depends
The design of system can depend on a lot of factors. Some of the factors include system requirements, user needs, expertise, budget and regulations.
Reiterating from previous point, choose what works for you. Here is summary image (generated with Grok AI)
Happy Building!