Real-Time Systems Engineering: WebSockets from Beginner to Senior-Level Architecture
Sep 24, 2026 · 20 min read
Real-Time Systems Engineering: WebSockets from Beginner to Senior-Level Architecture
A Progressive Project-Based Roadmap for Learning WebSockets, Distributed Systems, and Real-Time Architecture
The goal of this roadmap is not simply to learn how to use WebSockets.
The goal is to learn how to think about real-time systems like a senior engineer.
We will progressively build applications that introduce increasingly difficult problems:
- WebSocket connections
- Real-time events
- State synchronization
- Authentication
- Authorization
- Subscriptions
- Rooms and topics
- Message brokers
- Horizontal scaling
- Fan-out
- Backpressure
- Reconnection
- Event ordering
- Event replay
- Durable notifications
- Multi-tenancy
- RBAC
- ABAC
- ReBAC
- Failure recovery
- Observability
- Performance engineering
The projects become progressively more complex so that each new architecture concept solves a real problem introduced by the previous level.
1. The Core Mental Model
Before starting the projects, understand this fundamental architecture:
Database
Source of Truth
│
│
▼
API / Service
│
│ Domain Event
▼
Message Broker
Redis / NATS / Kafka
│
│ Event Distribution
▼
WebSocket Gateway
│
│ Push
┌────────┼────────┐
▼ ▼ ▼
User A User B User C
The responsibilities are different.
Database
The database is the source of truth.
It stores:
- users
- posts
- comments
- appointments
- notifications
- messages
- clinical records
- etc.
API / Backend
The backend changes application state.
For example:
POST /posts/123/like
The backend may:
1. Validate the request
2. Authorize the user
3. Update PostgreSQL
4. Commit the transaction
5. Publish an event
Message Broker
The broker distributes events between services and WebSocket servers.
Examples:
- Redis Pub/Sub
- Redis Streams
- NATS
- Kafka
- RabbitMQ
WebSocket
WebSocket provides a persistent connection between the client and server.
It is responsible for real-time delivery.
It is not the database.
It is not normally responsible for querying the database every time a message arrives.
Frontend
The frontend receives the event and updates its local state or cache.
2. Example: Social Media Like
Suppose a post currently has:
❤️ 120 likes
A user clicks Like.
The flow can be:
User
│
│ POST /posts/123/like
▼
API Server
│
│ INSERT/UPDATE
▼
PostgreSQL
│
│ Event
▼
Message Broker
│
▼
WebSocket Server
│
▼
Interested Clients
The WebSocket event might be:
{
"type": "LIKE_UPDATED",
"postId": "123",
"likeCount": 121
}
The frontend receives it:
❤️ 120
and changes it to:
❤️ 121
No additional HTTP request is required just to discover the new count.
3. One WebSocket Connection, Multiple Event Types
Do not normally create separate WebSocket connections for:
- likes
- dislikes
- comments
- notifications
Instead, use one persistent WebSocket connection.
Browser
│
│ One WebSocket
▼
WebSocket Server
Multiple events can travel through the same connection:
{
"type": "LIKE_UPDATED",
"postId": "123",
"likeCount": 501
}
{
"type": "DISLIKE_UPDATED",
"postId": "123",
"dislikeCount": 12
}
{
"type": "COMMENT_CREATED",
"postId": "123",
"comment": {
"id": "c789",
"userId": "45",
"content": "Nice post!"
}
}
The frontend can route events based on their type:
switch (event.type) {
case "LIKE_UPDATED":
// Update like count
break;
case "DISLIKE_UPDATED":
// Update dislike count
break;
case "COMMENT_CREATED":
// Append comment
break;
}
This is called multiplexing different event types over a single connection.
4. Connection vs Subscription
A very important distinction:
A WebSocket connection is not the same thing as a subscription.
You might have:
Browser
│
│ One WebSocket connection
▼
WebSocket Gateway
And over that connection:
subscribe(post:123)
subscribe(post:456)
subscribe(user:789)
For example:
{
"type": "SUBSCRIBE",
"postIds": ["101", "102", "103"]
}
Later:
{
"type": "SUBSCRIBE",
"postIds": ["102", "103", "104"]
}
The connection remains alive.
The subscriptions change.
5. Virtualized Social Media Feed
Imagine a social media application using React virtualization.
The browser might initially load:
GET /feed
The API returns lightweight post information:
Post
├── postId
├── authorId
├── authorName
├── content
├── likeCount
└── commentCount
You don't necessarily download thousands of comments for every post.
If the user opens comments:
User clicks Comments
│
▼
GET /posts/123/comments?limit=20
Then the application loads the comments.
The WebSocket can keep relevant information up to date.
6. WebSocket + Virtualization
The architecture can look like:
INITIAL LOAD
│
▼
HTTP API
│
▼
React Virtualized List
│
Visible Posts
│
▼
WebSocket Subscription
│
▼
WebSocket Gateway
│
┌─────────┼─────────┐
▼ ▼ ▼
Likes Comments Dislikes
│ │ │
└─────────┼─────────┘
▼
React State
│
▼
UI
When a post leaves the viewport:
unsubscribe(post:101)
When another post becomes relevant:
subscribe(post:104)
The physical WebSocket connection does not need to be recreated.
LEVEL 1 — BEGINNER
Goal
Understand WebSocket fundamentals before introducing distributed systems.
Do not start with:
- Kafka
- Kubernetes
- microservices
- complex authorization
- massive scaling
First understand the actual connection.
Project 1 — Live Counter
Build a real-time counter.
Architecture:
React
↕
WebSocket
↕
FastAPI
Features:
- Live counter
- Multiple browser tabs
- All connected clients receive updates
- Connection tracking
- Connect/disconnect handling
- Ping/pong heartbeat
- Reconnection
- Graceful shutdown
Example:
Tab A ─┐
Tab B ─┼──► WebSocket Server
Tab C ─┘
User clicks:
+1
Everyone receives:
{
"type": "COUNTER_UPDATED",
"value": 101
}
Concepts to learn
- WebSocket handshake
- Persistent connections
onopenonmessageoncloseonerror- Heartbeats
- Ping/pong
- Reconnection
- Connection lifecycle
- Graceful shutdown
Checkpoint
You should be able to explain:
What happens from the moment the browser connects to the WebSocket until it receives an event?
Project 2 — Real-Time Chat
Build a basic WhatsApp/Discord-style chat.
Features:
- One-to-one chat
- Chat rooms
- Online/offline status
- Typing indicator
- Message timestamps
- Message persistence
- Unread messages
- Reconnection
Architecture:
React
│
WebSocket
│
FastAPI
│
PostgreSQL
Database:
users
conversations
conversation_members
messages
Important lesson:
WebSocket messages are not your source of truth.
PostgreSQL persists the message.
WebSocket delivers it in real time.
Project 3 — Live Notification System
Build a notification system.
Features:
- Create notifications
- Read/unread status
- Mark as read
- Notification history
- Unread count
- Offline users
- Reconnection
- Notification persistence
Example database:
notifications
----------------
id
user_id
type
title
message
data
read_at
created_at
Now understand:
WebSocket = Real-time delivery
Database = Persistence
If the user is offline:
Event
│
▼
Notification DB
Later:
User logs in
│
▼
GET /notifications
│
▼
Unread notifications
Project 4 — Live Dashboard
Build a real-time admin dashboard.
Display:
Active Users
Orders
Revenue
Requests/sec
Errors
Update the dashboard in real time.
Introduce subscriptions:
subscribe("dashboard")
unsubscribe("dashboard")
Concepts
- Topics
- Subscriptions
- Unsubscriptions
- Server-side rooms
- Event filtering
Project 5 — Multiplayer Voting
Build a live voting application.
Example:
What database do you prefer?
PostgreSQL ██████████
MySQL █████
MongoDB ████
When someone votes:
Database
│
▼
Event
│
▼
WebSocket
│
▼
All subscribers
Concepts
- Broadcast
- Fan-out
- State updates
- Event types
- Multiple clients
- Synchronization
LEVEL 1 CHECKPOINT
At this point you should understand:
Browser
│
│ WebSocket
▼
Server
│
├── Connection management
├── Authentication
├── Events
├── Broadcast
└── Reconnection
You should be able to answer:
- What is a WebSocket?
- How is it different from HTTP?
- How does a connection get established?
- What happens when it disconnects?
- How do multiple clients receive the same event?
- Why shouldn't WebSocket itself be the source of truth?
LEVEL 2 — INTERMEDIATE
Now introduce distributed systems.
Technologies can include:
- Redis
- NATS
- Kafka
- Load Balancer
- Multiple WebSocket servers
- Authentication
- Authorization
- Subscription management
Project 6 — Distributed Chat
Take the previous chat application and scale it horizontally.
Architecture:
Load Balancer
/ | \
/ | \
WS-1 WS-2 WS-3
\ | /
\ | /
Redis
│
▼
PostgreSQL
Suppose:
User A → WS-1
User B → WS-3
User A sends a message.
The request might reach WS-1.
How does WS-1 deliver the message to User B connected to WS-3?
Introduce:
Redis Pub/Sub
Flow:
User A
│
▼
WS-1
│
▼
Redis
│
▼
WS-3
│
▼
User B
Concepts
- Horizontal scaling
- Load balancing
- Distributed WebSocket servers
- Redis Pub/Sub
- Connection distribution
- Distributed events
- Room membership
Project 7 — Real-Time Social Media
Build a simplified social media platform.
Entities:
users
posts
likes
comments
follows
notifications
Real-time events:
POST_CREATED
POST_UPDATED
LIKE_UPDATED
COMMENT_CREATED
COMMENT_DELETED
FOLLOW_CREATED
NOTIFICATION_CREATED
One WebSocket connection:
Browser
│
│ WebSocket
▼
WebSocket Gateway
Multiple subscriptions:
subscribe(post:123)
subscribe(user:456)
subscribe(feed:789)
Concepts
- Event types
- Topics
- Subscriptions
- Fan-out
- Rooms
- Connection management
- Horizontal scaling
Project 8 — Real-Time Collaboration Editor
Build a simplified Google Docs/Figma-style application.
Multiple users edit the same document:
User A ─┐
User B ─┼──► Collaboration Server
User C ─┘
Now you encounter:
- Concurrent updates
- Event ordering
- Conflicts
- Optimistic updates
- State synchronization
- Revision numbers
- Reconnection
- Recovery
Start with a server-authoritative model.
Later study:
- Operational Transformation (OT)
- CRDTs
This teaches an important concept:
WebSockets can be used for state synchronization, not only notifications.
Project 9 — Real-Time Delivery Tracking
Build a simplified Uber/DoorDash-style tracking system.
Architecture:
Driver
│
│ GPS updates
▼
Backend
│
▼
Customer
Features:
- Driver location
- Customer tracking
- Trip status
- ETA
- Connection recovery
- Location throttling
Suppose the driver produces:
20 GPS updates/sec
You might not want to send all 20 updates to the customer.
You could send:
2 updates/sec
Now you learn:
- Throttling
- Rate limiting
- Bandwidth optimization
- Message frequency
- Aggregation
- Backpressure
Project 10 — Real-Time Market Data Simulator
Do not build actual trading functionality.
Create a simulated market-data system.
Architecture:
Price Engine
│
▼
Message Broker
│
▼
WebSocket Cluster
│
▼
Clients
Features:
- Price updates
- Symbol subscriptions
- Multiple clients
- Batching
- Throttling
- Connection limits
Example:
Client A → subscribe(AAPL)
Client B → subscribe(TSLA)
Client C → subscribe(AAPL)
The server should only send relevant updates.
Now you're dealing with high-frequency events.
LEVEL 2 CHECKPOINT
You should now understand:
Single WebSocket Server
│
▼
Multiple WebSocket Servers
│
▼
Load Balancer
│
▼
Message Broker
│
▼
Topics / Subscriptions
│
▼
Fan-out
│
▼
Backpressure
│
▼
Reconnect / Recovery
At this point, you're no longer simply learning the WebSocket API.
You're learning distributed real-time systems.
LEVEL 3 — ADVANCED
HMS + Patient Portal
This is the capstone.
Now apply everything to a realistic healthcare management system.
Project 11 — Real-Time HMS
Build a healthcare management system with a patient portal.
High-level architecture:
┌─────────────────┐
│ Patient Portal │
└────────┬────────┘
│
WebSocket
│
┌────────▼────────┐
│ WebSocket │
│ Gateway │
└────────┬────────┘
│
┌────────▼────────┐
│ Event Broker │
│ Redis/NATS/Kafka │
└────────┬────────┘
│
┌───────────────┼───────────────┐
▼ ▼ ▼
Appointment Clinical Notification
Service Service Service
│ │ │
└───────────────┼───────────────┘
▼
PostgreSQL
Real-Time HMS Events
Appointment Events
APPOINTMENT_CREATED
APPOINTMENT_UPDATED
APPOINTMENT_CANCELLED
APPOINTMENT_CONFIRMED
APPOINTMENT_RESCHEDULED
Clinical Events
LAB_RESULT_AVAILABLE
LAB_RESULT_UPDATED
PRESCRIPTION_CREATED
VITAL_UPDATED
Patient Events
PATIENT_ADMITTED
PATIENT_DISCHARGED
Communication Events
MESSAGE_RECEIVED
MESSAGE_READ
TYPING_STARTED
TYPING_STOPPED
Notification Events
NOTIFICATION_CREATED
NOTIFICATION_READ
Project 12 — RBAC-Based Notifications
Introduce roles:
Doctor
Nurse
Receptionist
Admin
Patient
A clinical event might be:
{
"type": "LAB_RESULT_AVAILABLE",
"patientId": "P123",
"resourceId": "OBS456"
}
But don't simply broadcast it to every doctor.
You need to determine:
Is this user authorized to access this patient's information?
For example:
Doctor A
└── Treats Patient P123
Nurse B
└── Assigned to Patient P123
Doctor C
└── Works at same hospital but doesn't treat P123
Patient P123
└── Owns/is subject of their record
The notification recipients can therefore differ.
Project 13 — ABAC-Based Notifications
Now introduce Attribute-Based Access Control.
Potential attributes:
organizationId
departmentId
locationId
specialty
employmentStatus
patientRelationship
resourceSensitivity
Example policy:
user.organizationId == resource.organizationId
Another:
user.departmentId == patient.departmentId
Now the notification system isn't simply checking:
role == doctor
It is evaluating attributes.
Project 14 — ReBAC-Based Notifications
Healthcare is a good environment for Relationship-Based Access Control.
Think in terms of relationships:
Doctor ──TREATS──────► Patient
Nurse ──ASSIGNED_TO──► Patient
Doctor ──WORKS_AT────► Organization
Patient ──OWNS───────► PatientRecord
Instead of asking:
Is this user a doctor?
you ask:
What relationship does this user have with this patient/resource?
This is much more expressive for complex authorization systems.
Project 15 — Multi-Tenant HMS SaaS
Now turn the HMS into a SaaS platform.
For example:
Organization A
Organization B
Organization C
Organization D
Now tenant isolation becomes critical.
An event from:
Hospital A
must never reach:
Hospital B
Example event:
{
"type": "LAB_RESULT_AVAILABLE",
"organizationId": "ORG_A",
"patientId": "P123",
"resourceId": "OBS456"
}
The WebSocket connection should have tenant context:
userId
organizationId
roles
permissions
Then enforce:
event.organizationId
==
user.organizationId
before considering more detailed authorization.
Project 16 — Durable Notification System
Now deliberately disconnect users.
Suppose:
Patient is offline
│
▼
Lab result becomes available
WebSocket cannot deliver the notification.
Therefore:
Clinical Event
│
├──────────────► Notification DB
│
└──────────────► WebSocket
If the user is offline:
Notification DB
│
│ later
▼
Patient logs in
│
▼
GET /notifications
│
▼
Unread notifications
Example table:
notifications
-------------------------
id
user_id
organization_id
type
title
message
data
read_at
created_at
This introduces:
Real-time delivery + durable persistence.
Project 17 — Event Replay and Recovery
Now intentionally break the WebSocket connection.
Suppose:
Event 101 ✓
Event 102 ✓
Event 103 ✓
Connection lost
Event 104
Event 105
Event 106
Connection restored
How does the client know it missed events?
Introduce:
eventId
sequenceNumber
lastProcessedEvent
Client reconnects:
{
"lastEventId": 103
}
Server can recover:
104
105
106
Now you're learning:
- Reliable delivery
- Event replay
- Recovery
- Sequence numbers
- Idempotency
- Missed-event handling
Project 18 — Massive Notification Fan-Out
Now simulate a large-scale system.
For example:
1,000,000 users
100,000 concurrent connections
10,000 events/sec
You don't need a million physical machines.
Instead, simulate the workload.
Test:
10K connections
50K connections
100K connections
Measure:
CPU
RAM
Network bandwidth
Messages/sec
Latency
Connection count
Broker throughput
Database load
Now you're doing actual performance engineering.
Project 19 — Failure Engineering
This is one of the most valuable projects.
Start intentionally killing components.
Redis failure
Redis
X
What happens?
WebSocket server failure
WS-2
X
What happens to its clients?
Do they:
Reconnect
↓
Authenticate
↓
Resubscribe
↓
Recover missed events
Database failure
What happens when PostgreSQL becomes slow?
Broker failure
What happens when Redis/NATS/Kafka is unavailable?
Network failure
What happens when the client loses network connectivity for 30 seconds?
The goal of failure engineering
Don't just ask:
Does it work?
Ask:
What happens when it doesn't work?
That's where real system-design thinking begins.
7. WebSocket Architecture Concepts You Must Learn
The projects should eventually cover all of these.
| Concept | Question |
|---|---|
| Connection | How does a WebSocket connection work? |
| Lifecycle | What happens when it disconnects? |
| Heartbeat | How do I detect dead connections? |
| Reconnect | How does the client recover? |
| Authentication | How does a WebSocket authenticate? |
| Authorization | Who can subscribe to what? |
| Rooms | How do I group connections? |
| Topics | How do clients subscribe/unsubscribe? |
| Fan-out | How do I distribute one event to many users? |
| Scaling | How do multiple WS servers cooperate? |
| Broker | Why do I need Redis/NATS/Kafka? |
| Ordering | What happens if events arrive out of order? |
| Delivery | What happens if an event is lost? |
| Replay | How do I recover missed events? |
| Backpressure | What if clients cannot consume fast enough? |
| Throttling | What if events happen too frequently? |
| Persistence | What happens while the user is offline? |
| Multi-tenancy | How do I isolate organizations? |
| RBAC | Who can receive this? |
| ABAC | Under what attributes? |
| ReBAC | What relationship allows access? |
| Security | Can a user subscribe to another user's data? |
| Observability | How do I know the system is healthy? |
| Failure | What happens when Redis/WS/API dies? |
| Performance | How many connections/events can we handle? |
8. WebSocket Connection vs Message Rate
A very important scaling distinction:
10,000 concurrent connections
is not the same as:
10,000 messages/sec
For example:
100,000 connected clients
could produce:
500 messages/sec
Or:
10,000 connected clients
could produce:
100,000 messages/sec
These are completely different workloads.
WebSocket capacity depends on:
- Concurrent connections
- Messages/sec
- Message size
- Fan-out ratio
- CPU
- Memory
- Network bandwidth
- Subscription count
- Heartbeat frequency
- Authentication overhead
- Serialization cost
- Broker throughput
Therefore, don't think:
One server handles 10K users.
Instead think:
How many concurrent connections and messages/sec can this architecture sustain under this workload?
9. The Evolution of the Architecture
The entire learning path should evolve like this:
LEVEL 1
Browser
│
▼
WebSocket Server
│
▼
Database
Then:
LEVEL 2
Clients
│
▼
Load Balancer
│
├── WS-1
├── WS-2
└── WS-3
│
▼
Redis
│
▼
PostgreSQL
Then:
LEVEL 3
┌─────────────────┐
│ Patient Portal │
└────────┬────────┘
│
Load Balancer
│
┌──────────────┴──────────────┐
│ │
┌──────▼──────┐ ┌──────▼──────┐
│ API Cluster │ │ WebSocket │
│ │ │ Cluster │
└──────┬──────┘ └──────┬──────┘
│ │
│ Subscriptions
│ │
└──────────┬──────────────────┘
│
┌──────▼──────┐
│ Event Bus │
│ Redis/NATS │
│ / Kafka │
└──────┬──────┘
│
┌──────────────┼──────────────┐
│ │ │
Appointment Clinical Notification
Service Service Service
│ │ │
└──────────────┼──────────────┘
│
┌──────▼──────┐
│ PostgreSQL │
└─────────────┘
Around this architecture:
Authentication
Authorization
RBAC
ABAC
ReBAC
Multi-tenancy
Caching
Rate limiting
Security
Observability
Metrics
Tracing
Failure recovery
10. Complete Project Progression
Level 1 — WebSocket Fundamentals
1. Live Counter
2. Real-Time Chat
3. Live Notifications
4. Live Dashboard
5. Multiplayer Voting
Main objective
Learn:
Connections
Events
Broadcasting
Rooms
Reconnection
Heartbeats
Persistence
Level 2 — Distributed Real-Time Systems
6. Distributed Chat
7. Real-Time Social Media
8. Collaboration Editor
9. Delivery Tracking
10. Market Data Simulator
Main objective
Learn:
Redis/NATS/Kafka
Horizontal scaling
Load balancing
Subscriptions
Fan-out
Backpressure
Throttling
State synchronization
Event ordering
Level 3 — Advanced Real-Time Architecture
11. Real-Time HMS
12. RBAC Notifications
13. ABAC Notifications
14. ReBAC Notifications
15. Multi-Tenant HMS SaaS
16. Durable Notifications
17. Event Replay
18. Massive Fan-Out
19. Failure Engineering
Main objective
Learn:
Healthcare workflows
Patient portal
Authorization
RBAC
ABAC
ReBAC
Multi-tenancy
Durable events
Event replay
Reliability
Large-scale fan-out
Failure recovery
Observability
Performance engineering
11. The Senior Engineer Mindset
Don't approach these projects as:
"I need to make WebSockets work."
Instead, ask questions like:
Connections
How many connections can one server maintain?
Distribution
What happens when the user is connected to another WebSocket server?
Events
Where is the event generated?
Persistence
What happens if the user is offline?
Reliability
What happens if the event is lost?
Ordering
What if event 105 arrives before event 104?
Scaling
What happens when we have 100 WebSocket servers?
Fan-out
What happens if one event needs to reach one million users?
Authorization
Should this particular user receive this particular event?
Security
Can a malicious client subscribe to another patient's events?
Multi-tenancy
Can an event from Organization A reach Organization B?
Performance
What is consuming the CPU?
The connection?
Serialization?
Broker?
Database?
Network?
Failure
What happens if Redis dies?
What happens if PostgreSQL becomes unavailable?
What happens if the WebSocket server crashes?
Recovery
How does the client recover after reconnecting?
These questions are much more valuable than simply knowing the WebSocket API.
12. Final Architecture Mental Model
The final mental model should be:
CLIENT
│
│
WebSocket Connection
│
▼
WebSocket Gateway
│
Subscriptions
│
▼
Event Broker
│
┌────────────────┼────────────────┐
│ │ │
▼ ▼ ▼
Service A Service B Service C
│ │ │
└────────────────┼────────────────┘
│
▼
Database
And for notifications:
Domain Event
│
▼
Event Broker
│
▼
Notification Service
│
Authorization
┌─────────┼─────────┐
│ │ │
RBAC ABAC ReBAC
│ │ │
└─────────┼─────────┘
│
Authorized Users
│
┌──────────┼──────────┐
▼ ▼ ▼
Doctor Nurse Patient
WebSocket WebSocket WebSocket
And for persistence:
Domain Event
│
┌─────────┴─────────┐
▼ ▼
Notification DB WebSocket
│ │
│ ▼
│ Online User
│
▼
Offline User
│
│ Later
▼
Fetch Notifications
13. The Ultimate Goal
By the end of this roadmap, you should be able to look at an unfamiliar application and reason about its real-time architecture.
For example:
Healthcare
Trading
Gaming
Chat
Collaboration
Social Media
Logistics
IoT
Monitoring
Analytics
You should be able to ask:
1. What needs to be real-time?
2. What is the source of truth?
3. What events exist?
4. Who produces those events?
5. Who consumes them?
6. Who is authorized to receive them?
7. How are subscriptions represented?
8. How are events distributed?
9. Do we need a message broker?
10. How do we scale WebSocket servers?
11. What happens when a client disconnects?
12. What happens when a server dies?
13. What happens when the broker fails?
14. How do we recover missed events?
15. Do events need ordering?
16. Do events need persistence?
17. What happens when a client cannot consume fast enough?
18. How do we prevent unauthorized subscriptions?
19. How do we isolate tenants?
20. How do we observe and measure the system?
If you can answer these questions confidently, you're no longer just "someone who knows WebSockets."
You're developing the ability to design real-time distributed systems.
Final Learning Path
REAL-TIME SYSTEMS
│
▼
┌─────────────────┐
│ LEVEL 1 │
│ Fundamentals │
└────────┬────────┘
│
┌─────────────┼─────────────┐
▼ ▼ ▼
Counter Chat Notifications
│ │ │
└─────────────┼─────────────┘
▼
┌─────────────────┐
│ LEVEL 2 │
│ Distributed │
└────────┬────────┘
│
┌─────────────┼─────────────┐
▼ ▼ ▼
Social Media Collaboration Tracking
│ │ │
└─────────────┼─────────────┘
▼
┌─────────────────┐
│ LEVEL 3 │
│ Advanced │
└────────┬────────┘
│
▼
HMS + Patient Portal
│
┌────────────┼────────────┐
▼ ▼ ▼
RBAC ABAC ReBAC
│ │ │
└────────────┼────────────┘
▼
Multi-Tenant SaaS
│
▼
Event Replay/Recovery
│
▼
Massive Fan-Out
│
▼
Failure Engineering
│
▼
Production Architecture
The objective is not to finish 19 projects as quickly as possible.
The objective is to make every project introduce a new architectural problem, solve it, measure it, break it, and understand why the next architectural component becomes necessary.
That is how you move from learning an API to learning real-time systems engineering.