Interactive System Designing
Build a system design diagram
Pick what your system must do and how well it must do it. The diagram adds the parts each choice relies on. Click any box to see what it does.
Click a box in the diagram to see what it does.
How to use the builder
- Tick the features your system needs.
- Tick the qualities that matter most.
- Click any box in the diagram to see what that part does and why it was added.
What the main parts do
- Load balancer: shares incoming requests across several copies of each service, so no single server is overloaded.
- CDN: serves images and files from servers close to each user.
- Cache: keeps frequently used data in memory (for example Redis), so repeat requests skip the slower database.
- Message queue: holds events until a service is ready, so slow jobs such as sending email run in the background.
- Read replicas: copies of the database that handle read requests and spread the load.
- Standby database and health checks: take over when something fails, so the system keeps running.
- Object storage: cheap, durable storage for uploads and large files.
Example
Tick User login, File and image uploads and Scalability. The diagram adds an auth service, an upload service with object storage, and, for scalability, an auto-scaler, a cache, a message queue and read replicas, with several copies of each service.
Frequently asked questions
Is this diagram a complete design?
No. It shows the common building blocks for each choice. A real design also depends on traffic, budget, team size and data rules.
Why does real-time chat add new parts?
Chat needs a connection that stays open, so the diagram adds a WebSocket server and a chat service, plus a cache and a message queue to pass new messages between servers quickly.
Learn how systems talk to each other in Webhook vs polling.
One Response