A system design diagram can contain all the right boxes and still leave the reader wondering what actually happens.
Where does a request start? What does each arrow mean? Which part of the design needs a discussion?
I'm Darshit, the creator of DrawDesign, a browser-based tool for system architecture diagrams and flowcharts. In this post, I'll introduce the tool and share a small exercise you can use to make your next diagram easier to explain.
What is DrawDesign?
DrawDesign provides a canvas with shapes for the components developers often need to describe: servers, databases, load balancers, caches, message queues, API gateways, containers, and Kubernetes.
The shape library also covers networking and security, data and analytics, monitoring, and DevOps. The editor includes templates and an AI Assistant.
The use cases I want to support are straightforward:
- Sketching an architecture before implementing it.
- Explaining a request flow to another developer.
- Practising system design discussions.
- Turning a rough workflow into a diagram people can review.
But choosing a diagramming tool is only one part of the work. The more useful question is: what should the diagram communicate?
A small exercise: explain one request
Imagine you're sketching a product catalogue API. Resist the temptation to draw every service the application might eventually need. Start with one question:
How does a user request product details?
1. Draw only the participants in that path
Begin with a client, an API, and a database. Give them specific names: “Web client,” “Product API,” and “Product database” communicate more than three identical boxes labelled “service.”
Keep the scope visible in a note: “Product detail reads.” Someone looking at this diagram should not have to guess whether it also covers checkout, inventory updates, or payment processing.
2. Label the arrows
An arrow tells the reader that two components interact. Its label tells them why.
For this exercise, use labels such as:
| Connection | Example label |
|---|---|
| Client to API | Request product details |
| API to database | Look up product by ID |
| API to client | Return product details or an error |
You don't need to put every implementation detail on the canvas. Include the information someone needs to follow the story.
3. Add a cache as a design question
Now add a cache shape. Before drawing more arrows, write down the decisions you need to make:
- What data would go into it?
- How would the system handle a missing entry?
- How would updated product data become visible?
- What should happen if the cache is unavailable?
These questions are more valuable than adding a cache icon just because it appears in other architecture diagrams. The drawing should expose decisions that still need an answer.
4. Make uncertainty visible
Use notes to distinguish an agreed decision from an assumption. For example:
Open question: how fresh must product descriptions be?
Or:
Scope: this diagram describes reads only; inventory updates are a separate flow.
This keeps a clean-looking diagram from implying that every tradeoff has already been settled.
5. Ask another developer to narrate it
Show someone the diagram without explaining it first. Ask them where a request starts, what happens next, and which failure case deserves attention.
If their interpretation differs from yours, that is useful feedback. Rename a component, label a connection, or split an overloaded diagram into smaller views.
Where DrawDesign fits
This is the kind of exercise I'd like people to try in DrawDesign. Pick the components you need, sketch the flow, and use the result as the starting point for a discussion.
The infrastructure shapes help express the components in that story. Templates and the AI Assistant are additional starting points, but the architecture still needs your reasoning: requirements, assumptions, and tradeoffs should remain explicit.
I don't want feedback to stop at “the UI looks good.” The most useful feedback is specific:
- Which component was difficult to find?
- Which editing step interrupted your explanation?
- What would make the diagram easier to use in a design review?
- Which template would you actually reuse?
Try it with a real problem
Open DrawDesign using the link above and sketch one flow from a project you understand. Keep it small enough that another developer can follow it without a guided tour.
What is your biggest frustration with system design diagramming tools? Share a concrete example in the comments—I'd like that feedback to shape what I improve next.
Top comments (0)