System Design master Template

 A Master Microservice-Based System Design

Article By: Radhakrishnan A Perumal

A simple example from a microservice perspective:
Let’s say you have a Patient Service calling a Notification Service to send emails.
Looks clean.
Looks simple.
Looks like something you can explain in 10 seconds.
But system design starts when you ask:

1. What happens if Notification Service is slow or offline?
Do we retry?
Do we queue the request?
Do we return success to the user or fail the entire operation?
There’s no “one correct answer”, there’s only the answer that won’t break your system.

2. Should the Patient Service call Notification directly… or produce an event?
Direct call means tight coupling.
Events mean eventual consistency.
Which one fits your domain?
Which one will still make sense when you have 8 services, not 2?

3. What if email sending spikes?
Do we scale horizontally?
Rate limit?
Batch processing?
Move heavy tasks to background workers?
Most outages happen because developers never asked this question early enough.

4. How do we trace failures across services?
Without proper logs, metrics, and correlation IDs, debugging becomes guesswork.
System design includes observability, not as an afterthought, but as part of the plan.
...who can think through:
• latency
• failure patterns
• data consistency
• backpressure
• scaling behavior
• real-world growth