System Design Roadmap: 17 Core Concepts Every Architect Must Know
Don't start coding without a 30,000-foot view. This comprehensive guide breaks down the essential pillars of system design, from Consistency Models and Polyglot Persistence to Cost Optimization and Scaling Strategies. A must-read checklist for building robust software.
I had this article in my head for two years but hesitated to write it, worrying about the ever-changing technology landscape. Tools evolve, but core concepts remain. This is a documentation of the fundamental pillars of system design. We can always fine-tune the specifics based on infrastructure and requirements, but the foundation must be solid.
System design is an essential part of software development. You must have a 30,000 ft view before digging into specifics. General-purpose programming languages can be used everywhere, but knowing where and how to use them is where system design comes into the picture.
Here are the 17 important steps and concepts necessary for architecting a robust system.
1. UX Design & Components
Since you will most likely not be developing a CLI-only tool, having a solid UX/UI strategy is crucial. Identify the core components early. For example:
- Twitter Clone: Tweet drafter, user profiles, feed, privacy settings.
- Uber Clone: Maps integration, location tracking.
- Messenger: P2P messaging, group chats, media sharing.
Categorize the app design based on its domain (Social, OTT, Booking, etc.).
╔═════════════════════════════════════╗
║ TWITTER CLONE UI COMPONENTS ║
╠═════════════════════════════════════╣
│ APPLICATION UI │
├─────────────────────────────────────┤
│ ┌──────────┐ ┌──────────┐ │
│ │ Profile │ │ Tweet │ │
│ │Component │ │Component │ │
│ └──────────┘ └──────────┘ │
│ ┌──────────┐ ┌──────────┐ │
│ │ Settings │ │ Messages │ │
│ │Component │ │Component │ │
│ └──────────┘ └──────────┘ │
└─────────────────────────────────────┘
2. Classes/Subclasses
For object-oriented design, list the various classes required. This helps chalk out objects and define methods. For a Twitter clone, you might have a "User" class.
╔═════════════════════════════════════╗
║ OBJECT-ORIENTED CLASS DESIGN ║
╚═════════════════════════════════════╝
┌─────────────────┐
│ User │
├─────────────────┤
│ - name │
│ - location │
│ - email │
├─────────────────┤
│ + post() │
│ + follow() │
└────────┬────────┘
│
┌────────┴────────┐
│ │
┌───▼────┐ ┌─────▼───┐
│Premium │ │ Basic │
│ User │ │ User │
└────────┘ └─────────┘
3. Design Patterns
Select an adequate design pattern. For a news feed or notification system, the Publisher-Subscriber pattern is often the standard choice.
╔═════════════════════════════════════╗
║ PUBLISHER-SUBSCRIBER PATTERN ║
╚═════════════════════════════════════╝
┌──────────────┐
│ Publisher │
│ (News Feed) │
└──────┬───────┘
│
│ publish()
│
┌───▼────────────────┐
│ Message Broker │
└───┬────────────────┘
│
│ notify()
│
┌───┴───┬───────┬────────┐
│ │ │ │
┌──▼──┐ ┌──▼──┐ ┌──▼──┐ ┌───▼─┐
│Sub1 │ │Sub2 │ │Sub3 │ │Sub4 │
└─────┘ └─────┘ └─────┘ └─────┘
4. Infrastructure Stack (CDN/Serverless/API/Cache)
- CDN: Host static HTML/Assets with lower latency.
- Serverless: Reduce costs for simple automation or cron jobs.
- APIs: Connect disconnected systems and enable separation of concerns.
- Cache: Store temporary hot data. Note: Cache memory is expensive, so use an optimized strategy.
╔═════════════════════════════════════╗
║ CDN/SERVERLESS/API/CACHE STACK ║
╚═════════════════════════════════════╝
┌─────────┐
│ Client │
└────┬────┘
│
▼
┌─────────────┐ ┌──────────┐
│ CDN │◄───│ Static │
│ (Static) │ │ Content │
└────┬────────┘ └──────────┘
│
▼
┌─────────────┐ ┌──────────┐
│ Cache │◄───│ Hot │
│ │ │ Data │
└────┬────────┘ └──────────┘
│
▼
┌─────────────┐ ┌──────────┐
│ API │◄───│Serverless│
│ Gateway │ │Functions │
└────┬────────┘ └──────────┘
│
▼
┌─────────────┐
│ Backend │
│ Server │
└─────────────┘
5. Eventual Consistency vs. Transactional Consistency
- Eventual Consistency (NoSQL): Expect some delay. Suitable for social feeds or non-critical data where a 2-3 second delay is acceptable.
- Transactional Consistency (SQL): Immediate commit. Critical for financial transactions (e.g., money transfer) to prevent double-spending.
╔═════════════════════════════════════════════════════════════╗
║ EVENTUAL vs TRANSACTIONAL CONSISTENCY ║
╚═════════════════════════════════════════════════════════════╝
EVENTUAL CONSISTENCY TRANSACTIONAL CONSISTENCY
┌──────────────────┐ ┌──────────────────┐
│ Write Request │ │ Write Request │
└────────┬─────────┘ └────────┬─────────┘
│ │
▼ ▼
┌─────────┐ ┌─────────┐
│ NoSQL │ │ SQL │
│ DB │ │ DB │
└────┬────┘ └────┬────┘
│ │
┌────▼────┐ ┌────▼────┐
│ Delay │ │Immediate│
│ 2-3 sec │ │ Commit │
└────┬────┘ └────┬────┘
│ │
▼ ▼
[Eventually [Immediately
Consistent] Consistent]
6. Event Handling
Clearly define the routes data packets will take from request initiation to response fulfillment.
╔═════════════════════════════════════╗
║ EVENT HANDLING FLOW ║
╚═════════════════════════════════════╝
┌──────────┐ Event ┌──────────┐
│Component │─────────────►│ Event │
│ A │ Fired │ Queue │
└──────────┘ └─────┬────┘
│
┌─────▼─────┐
│ Handler │
└─────┬─────┘
│
┌───────────┼───────────┐
│ │ │
┌───▼───┐ ┌───▼───┐ ┌───▼───┐
│Comp B │ │Comp C │ │Comp D │
└───────┘ └───────┘ └───────┘
7. SQL / NoSQL / Polyglot Persistence
According to the CAP theorem, in a distributed system with partitions, you must choose between Consistency and Availability.
- SQL: Structured data, ACID compliant. Prioritizes Consistency (CP).
- NoSQL: Semi-structured data (Key-value, Document, Graph). Prioritizes Availability (AP).
- Polyglot Persistence: Using a combination of both to suit different data needs.
╔═════════════════════════════════════╗
║ SQL/NoSQL/POLYGLOT PERSISTENCE ║
╚═════════════════════════════════════╝
┌─────────────────────────────────────┐
│ Application Layer │
└──────────────┬──────────────────────┘
│
┌───────┴────────┐
│ │
┌──────▼──────┐ ┌─────▼────────────┐
│ SQL │ │ NoSQL │
│ Database │ │ Database │
├─────────────┤ ├──────────────────┤
│ - ACID │ │ - Key-Value │
│ - Structured│ │ - Document │
│ - CA (CP) │ │ - Graph │
│ │ │ - AP │
└─────────────┘ └──────────────────┘
└────────┬────────┘
│
POLYGLOT PERSISTENCE
8. Client-Side vs. Server-Side Storage
Define where data lives. WhatsApp stores messages locally; Facebook Messenger stores them on servers. Decide this early.
╔═══════════════════════════════════════════════════╗
║ CLIENT-SIDE vs SERVER-SIDE STORAGE ║
╚═══════════════════════════════════════════════════╝
CLIENT-SIDE SERVER-SIDE
┌──────────────┐ ┌──────────────┐
│ Mobile │ │ Server │
│ Device │ │ Cluster │
├──────────────┤ ├──────────────┤
│ ┌──────────┐ │ │ ┌──────────┐ │
│ │ WhatsApp │ │ │ │ Facebook │ │
│ │ Messages │ │ │ │Messenger │ │
│ │ (Local) │ │ │ │ Messages │ │
│ └──────────┘ │ │ └──────────┘ │
│ │ │ │
│ + Optional │ │ + Backup │
│ Cloud │ │ + Sync │
│ Backup │ │ + Access │
└──────────────┘ └──────────────┘
9. Optimized Data Structures
Every line of code taxes the server. Use data structures with lower time and space complexities to reduce maintenance costs and improve performance.
╔═════════════════════════════════════╗
║ OPTIMIZED DATA STRUCTURES ║
╚═════════════════════════════════════╝
Data Structure Complexity
O(1) ───────── Best (Hash Table)
O(log n) ────── Good (Binary Tree)
O(n) ───────── Acceptable (Array)
O(n²) ───────── Poor (Nested Loops)
O(2ⁿ) ───────── Worst (Exponential)
┌─────────────────────────────┐
│ Choose Lower Complexity │
│ = Less Server Tax │
│ = Lower Costs │
└─────────────────────────────┘
10. Privacy Settings
Users must have control. Implement features like hiding profile photos, read receipts, last seen status, and blocking capabilities.
+-----------------------------------------+
| PRIVACY SETTINGS |
+-----------------------------------------+
+-----------------------------------------+
| User Privacy Panel |
+-----------------------------------------+
| [ ] Show Profile Photo |
| [X] Hide Last Seen |
| [X] Hide Read Receipts |
| [ ] Show Online Status |
| [X] Block User |
| |
| [Save Settings] |
+-----------------------------------------+
11. Compliance
- HIPAA: Required for applications handling Protected Health Information (PHI).
- GDPR: Required for applications launching in the EU.
╔═════════════════════════════════════╗
║ COMPLIANCE REQUIREMENTS ║
╚═════════════════════════════════════╝
┌──────────────────────────────────┐
│ Your Application │
└────────────┬─────────────────────┘
│
┌──────┴──────┐
│ │
┌─────▼─────┐ ┌────▼──────┐
│ HIPAA │ │ GDPR │
│Compliance │ │Compliance │
├───────────┤ ├───────────┤
│ Medical │ │ EU │
│ PHI │ │ Privacy │
│ Protected │ │ Rules │
└───────────┘ └───────────┘
12. Security Layers
Consider a multi-layered security approach:
- Layer 1: Strong Password Policies
- Layer 2: Spam Filtering
- Layer 3: DDoS Protection
- Layer 4: IAM & Access Control
- Layer 5: 2FA Authentication
13. Geographic Availability
Ensure your dependencies are available in the target region. For example, relying on Google/Facebook APIs for an app launching in China will cause failure.
+---------------------------------------+
| GEOGRAPHICAL SERVICE AVAILABILITY |
+---------------------------------------+
GLOBAL SERVICE MAP
+--------------+ +--------------+
| USA | | China |
+--------------+ +--------------+
| [+] Facebook | | [-] Facebook |
| [+] Google | | [-] Google |
| [+] AWS | | [+] Alibaba |
| [+] WhatsApp | | [+] WeChat |
+--------------+ +--------------+
Check Service Availability Before Launch!
14. Cost Analysis
Balance cost vs. performance. Prioritize open-source over proprietary when possible. Use serverless for sporadic workloads.
╔═════════════════════════════════════╗
║ COST OPTIMIZATION ║
╚═════════════════════════════════════╝
┌────────────────────────────────────┐
│ Cost Optimization │
├────────────────────────────────────┤
│ │
│ Open Source >>> Proprietary │
│ (Lower Cost) (Higher Cost) │
│ │
│ Serverless >>> Always-On │
│ (Pay per use) (Fixed Cost) │
│ │
│ Cache >>> DB Query │
│ (Expensive) (Cheaper) │
│ │
└────────────────────────────────────┘
Balance Cost vs Performance
15. Deployment (On-Prem/Cloud/Hybrid)
Decide on the infrastructure model. Will you use a VPC? Will you keep sensitive data on-premise while bursting compute to the cloud (Hybrid)?
╔═════════════════════════════════════╗
║ DEPLOYMENT OPTIONS ║
╚═════════════════════════════════════╝
┌──────────────────────────────────────┐
│ Deployment Options │
└───────────┬──────────────────────────┘
│
┌───────┼───────┐
│ │ │
┌───▼───┐ ┌─▼────┐ ┌▼──────┐
│On-Prem│ │Cloud │ │Hybrid │
├───────┤ ├──────┤ ├───────┤
│Local │ │ AWS │ │On-Prem│
│Servers│ │Azure │ │ + │
│ Data │ │ GCP │ │ Cloud │
│Center │ │ │ │ Mix │
└───────┘ └──────┘ └───────┘
│
┌───▼────┐
│ VPC │
└────────┘
16. Horizontal vs. Vertical Scaling
- Horizontal Scaling: Adding more replicas/instances. Requires Load Balancers. Preferred for high availability.
- Vertical Scaling: Increasing CPU/RAM of a single instance. Has physical limits.
+-------------------------------------------------------------+
| HORIZONTAL & VERTICAL SCALING WITH LOAD BALANCERS |
+-------------------------------------------------------------+
HORIZONTAL SCALING VERTICAL SCALING
+---------------+ +---------------+
| Load Balancer | | Upgrade |
+-------+-------+ | CPU + RAM |
| +-------+-------+
| |
+-------------+-------------+ |
| | | |
v v v (and v) v
+---+ +---+ +---+ +---------------+
|DB1| |DB2| |DB3|... | Powerful |
+---+ +---+ +---+ | Server |
+---------------+
Add more servers Improve single server
17. Customer Acquisition & Analytics
Build analytics into the design. Use Funnel Analytics and A/B Testing to understand user behavior and improve retention.
╔═════════════════════════════════════╗
║ CUSTOMER ACQUISITION & RETENTION ║
╚═════════════════════════════════════╝
┌─────────────────────────────────────┐
│ Analytics Funnel │
├─────────────────────────────────────┤
│ │
│ 1000 Users ▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓ │
│ │ │
│ 500 Signups ▓▓▓▓▓▓▓▓▓ │
│ │ │
│ 200 Active ▓▓▓▓ │
│ │ │
│ 100 Paid ▓▓ │
│ │
├─────────────────────────────────────┤
│ A/B Testing │
│ ┌─────────┐ ┌─────────┐ │
│ │Version A│ │Version B│ │
│ │ 50% │ │ 50% │ │
│ └────┬────┘ └─────┬───┘ │
│ └──────┬────────┘ │
│ Compare │
└─────────────────────────────────────┘
This framework is a solid foundation for designing scalable software and can also serve as a guide for clearing system design interviews.
If you have any questions, feel free to connect on LinkedIn.
What's Your Reaction?
Like
0
Dislike
0
Love
0
Funny
0
Angry
0
Sad
0
Wow
0
