Premium Video

This video is available to premium subscribers only

Unlock Full Access

In this chapter, we'll learn how to draw clear, easy-to-follow diagrams during system design interviews.

We'll use a common interview problem, designing a news feed similar to Facebook or Instagram, to walk through the process step by step.

In a system design interview, your diagram helps the interviewer understand your design and follow your thought process.

A good diagram serves two main purposes:

Most system design interviews today are conducted virtually, so you'll usually create diagrams using tools like Excalidraw, Miro, or whatever whiteboard tool the company provides. In onsite interviews, you might still use a physical whiteboard.

Regardless of the tool, make sure you're comfortable using it before the interview. Struggling with basic controls can waste valuable time and take your attention away from the actual design.

If you don't know which tool the company uses, ask your recruiter ahead of time. Once you know, spend some time practicing with it. Get comfortable with basic actions like:

Ideally, try drawing a complete system design using the tool. Even 10 minutes of practice can make a difference.

If you're using a physical whiteboard, the main challenge is managing space. Start with smaller components and leave enough room on the right and bottom, since you'll likely need to expand your diagram as the discussion progresses.

Before you start drawing, spend a moment thinking about how to organize your diagram.

For most system designs, a left-to-right layout works well:

This follows the natural flow of a request through the system, making the diagram easier to understand.

As you arrange these components, make sure to leave enough space for additional details. During the deep dive, you might need to introduce a message queue between services or add a cache in front of a database. If your diagram is already crowded, these changes become difficult to show clearly.

It's also useful to reserve some space at the top or along one side for important notes, such as requirements, traffic estimates, and API definitions. This keeps the information visible and easy to refer to throughout the interview.

For a news feed system, your notes might look something like this:

Keep these notes short and focused on the important details. You don't need to write complete sentences or lengthy explanations, since that takes up valuable interview time.

Having this information visible becomes useful as the discussion progresses. For example, during a deep dive, you can refer to the eventual consistency requirement to explain why asynchronous fan-out is a reasonable choice. Toward the end of the interview, you can revisit the requirements and quickly check whether your design addresses each one.

Every box in your diagram should have a clear, descriptive label. The more specific the label, the easier it is for the interviewer to understand your design.

A label like "Posts DB (PostgreSQL)" tells the interviewer what the component stores and which technology you're using. The same applies to services. Generic labels like "Backend" or "Server" don't explain much, while "Post Service" and "Feed Service" make the responsibilities clear.

For important data stores, you can also add a short note showing the key fields:

You don't need to show the entire schema. Just include enough detail to explain what you're storing.

Finally, try to use consistent shapes throughout your diagram. A common convention is:

Whatever convention you choose, stick to it so the interviewer can easily recognize each component.

Arrows are another important part of a system design diagram, and they can quickly make it difficult to read if you're not careful. To keep things clear, follow a few simple practices.

1. Draw arrows in the direction of the request

An arrow from the feed service to the feed cache indicates that the feed service calls the cache. The response is usually implied, so you don't need a separate arrow pointing back.

2. Label arrows when the interaction isn't obvious

Labels like "Read feed", "Publish post event", or "Write post" help the interviewer understand what's happening.

3. Use different line styles for synchronous and asynchronous communication

For example, you can use solid lines for direct calls and dashed lines for asynchronous messages sent through a queue.

In our news feed example, this distinction is particularly useful. When a user creates a post, the client waits for the post service to save it. But distributing that post to followers' feeds happens asynchronously in the background.

Showing these as different types of connections makes the flow easier to understand without needing a lengthy explanation. If you use a line style that might not be obvious, add a small legend in a corner of the diagram.

Instead of drawing the entire architecture at once and explaining it afterward, build your diagram one step at a time, starting with the main APIs.

For our example, begin with the POST /posts API for creating a new post. Draw the client, API gateway, post service, and posts database. As you add each component, explain its role in the request:

Next, move to the GET /feed API. Add the feed service and any additional components it needs, while reusing the ones you've already drawn.

For flows involving multiple steps, you can also number the arrows to make the sequence easier to follow. For example, when a user creates a post:

In many systems, reads and writes have different requirements. A news feed is a good example. Users typically read their feeds much more often than they create posts.

In such cases, it helps to show the read and write paths separately in your diagram. You could place the write path at the top and the read path at the bottom, or use different colors to distinguish them.

For our news feed example:

With this layout, it's easy to see how both paths connect through the feed cache. It also highlights an important design decision: we're doing additional work when posts are created so that reading the feed becomes much faster.

Separating these paths visually also makes scaling discussions easier, since the interviewer can see which components handle reads and writes and how they can scale independently.

Your diagram should evolve as you make design decisions. If you introduce an important change during a deep dive but don't update the diagram, it no longer represents the design you've discussed.

For example, suppose the interviewer asks:

"What happens when a celebrity with 50 million followers creates a post?"

Adding that post to 50 million cached feeds would take considerable time and put a heavy load on the fan-out workers.

One way to handle this is with a hybrid approach. For regular users, we continue to distribute posts to followers' feeds when they're created. But for accounts with millions of followers, we skip this step. Instead, the feed service fetches their recent posts at read time and merges them with the cached feed.

To show this change:

There's no need to redraw the entire architecture. Just update the existing diagram, and if your tool allows it, use a different color to highlight changes made during the deep dive. This helps the interviewer see how your design has evolved.

And if a decision replaces an earlier component or connection, remove or cross out the old one. Otherwise, it becomes unclear which parts belong to the final design.

A good system design diagram should focus on the components that matter. Trying to include every possible component can make the diagram cluttered and harder to understand.

Some infrastructure details can be left out unless they're relevant to the discussion:

A useful rule is to draw a component when it affects the system's behavior or supports an important design decision. For example, showing a CDN in a news feed system makes sense because it explains how images and videos are delivered efficiently. But a secrets manager probably doesn't need to appear in the main diagram.

Keeping your diagram focused also helps you avoid unnecessary complexity. Whenever you introduce a new component, make sure you can explain why it's needed and what problem it solves.

Let's look at two common mistakes that can make your diagrams harder to follow.

1. Making the diagram too crowded

Crossing arrows, overlapping boxes, and small labels can make even a good design difficult to understand. If your diagram starts getting messy, take a few seconds to rearrange the components and leave more space between them. Most digital whiteboard tools make this easy.

2. Trying to make the diagram look perfect

Consistent colors and proper alignment can improve readability, but they're less important than clearly explaining your design. Focus on keeping your diagram clean and easy to follow, rather than making every detail look polished.

Remember, the goal isn't to create a perfect diagram. It's to communicate your design clearly, help the interviewer follow your reasoning, and keep your discussion organized.