Design Twitter's Architecture in UML

Model Twitter's distributed system with UML diagrams in draw.io.

Introduction

30 Second Summary

When you open Twitter, your timeline loads in milliseconds. Behind that instant feed is a distributed system handling 400 billion events per day, routing tweets through message queues, caches, and microservices.

In this project, you will design Twitter's distributed architecture as a set of professional UML diagrams in draw.io. You will model the component layout, the tweet publish flow, the hybrid fan-out read path, and the deployment infrastructure across multiple diagram pages.

What You'll Build

A professional, multi-page UML architecture diagram of Twitter's distributed system in draw.io, covering microservices, Apache Kafka event streaming, caching layers, and multi-region deployment.

By the end of this project, you'll have:

A complete 4-page UML diagram set modeling Twitter's architecture with component, sequence, and deployment diagrams ready to reference in interviews.
Fluency with draw.io's UML tools including shape libraries, connector styles, multi-page navigation, and styling to rapidly sketch architecture diagrams under time pressure.
A reusable mental framework for structuring system design diagrams layer-by-layer in interviews (components, sequences, deployment).
Secret Mission: Add a fifth page modeling the notification and trending topics pipeline as a UML activity diagram with swimlanes.

Are there any prerequisites?

None. This guide includes full draw.io orientation for beginners. You only need a web browser. draw.io runs entirely in the browser at app.diagrams.net with no account or installation required.

Before We Start

Before We Start...

Set Up draw.io and Configure Your UML Workspace

Before you can model Twitter's distributed architecture, you need a diagramming workspace configured for UML.

In this step, you will open draw.io in your browser, create a new diagram file, and enable the shape libraries you need for professional architecture diagrams.

In this step, get ready to:

Create a new diagram file in draw.io saved to your local device.
Enable UML and Network shape libraries for architecture diagramming.
Orient yourself to the draw.io editor layout.

Open draw.io and create a new diagram

draw.io is a free web-based diagramming tool that runs entirely in your browser. No account or installation is needed.

Open a new browser tab and navigate to app.diagrams.net.
When the storage prompt appears, select Device.

Why Device storage?

Selecting Device keeps your diagram file saved locally on your Mac. You do not need a cloud account or login to complete this project.

Click Create New Diagram.
In the filename field at the top, replace the default name with twitter-architecture.drawio.
Select Blank Diagram from the template list.
Click Create.

You should now see an empty canvas with a grid background. This is your draw.io editor.

Don't see the Create New Diagram option?

If draw.io opens directly to an empty canvas, it may have remembered a previous session. Go to File > New in the top menu bar to trigger the new diagram dialog.

Help me create a new blank diagram in draw.io

Enable UML shape libraries

draw.io ships with over 220 UML shapes, but they are not visible by default. You need to enable the UML libraries before you can drag architecture shapes onto your canvas.

Click + More Shapes at the bottom of the left panel.
Scroll down to the Software section.
Check both the UML and UML 2.5 checkboxes.
Scroll to the Networking section and check the Network checkbox.
Click Apply.

Your left panel should now show UML shape categories including components, lifelines, and deployment nodes. You will use these throughout the project.

Why three libraries?

The UML library gives you classic shapes like class diagrams and basic connectors. UML 2.5 adds modern shapes like lifelines, activation bars, and interaction fragments for sequence diagrams.

The Network library provides cloud and server shapes you will need for the deployment diagram in Step 6.

Don't see UML shapes in the left panel?

Make sure you clicked Apply after checking the boxes. If the libraries still do not appear, try refreshing the page and re-enabling them from + More Shapes.

Help me enable UML shape libraries in draw.io

Orient yourself to the editor layout

The draw.io editor has three key areas you will use constantly. Knowing where everything lives now saves time when you are building diagrams under interview pressure.

Look at the left panel. This is your shape library. You drag shapes from here onto the canvas. Expand the UML and UML 2.5 categories to preview what is available.
Look at the center area. This is your drawing canvas with a grid for alignment. All your diagram shapes will live here.
Look at the right panel. This is the Format panel with Style, Text, and Arrange tabs. These appear when you select a shape or connector.
Locate the toolbar above the canvas. Find the zoom controls, undo/redo buttons, and the connector tool.

Keyboard shortcuts to remember

These shortcuts will speed up your diagramming in later steps. Cmd+G groups selected shapes. Cmd+D duplicates a shape. Cmd+S saves your diagram.

Your workspace is ready. Next up, you will learn draw.io's core mechanics by practicing with shapes and connectors before building the real architecture diagrams.

Master draw.io Fundamentals with a Practice Diagram

Before you build a multi-page architecture diagram under interview pressure, you need muscle memory with draw.io's tools.

In this step, you'll practice the three core skills that make draw.io diagrams look professional: placing and connecting shapes, styling connectors with proper UML notation, and using alignment tools to keep layouts clean.

In this step, get ready to:

Place shapes and create connectors between them.
Style connectors with UML-specific arrowheads and line patterns.
Align and group shapes for clean diagram layouts.

Practice placing and connecting shapes

Every architecture diagram starts with shapes that represent components and connectors that show relationships between them.

In the left panel, find the General shape library.
Drag a rectangle from the library onto the center canvas.
Double-click the rectangle to enter editing mode.
Type User Service as the label, then click anywhere outside the shape to confirm.
Drag a second rectangle onto the canvas to the right of the first one.
Label it Tweet Service by double-clicking and typing.

You should see two labeled rectangles sitting side by side on your canvas.

Hover your mouse over the first shape (User Service) until you see blue arrow indicators appear on its edges.
Click and drag from one of the blue arrows toward the second shape (Tweet Service).
Release your mouse when the second shape highlights, indicating the connector will attach to it.

You should now see a line with an arrowhead connecting your two shapes.

What are the blue arrow indicators?

The blue arrows that appear when you hover over a shape are connection points.

When you drag from a blue arrow to another shape, draw.io creates a connector that stays attached to both shapes even when you move them around.

Connector not attaching?

Make sure you start dragging from the blue arrow indicator on the edge of the first shape, not from the shape's center.

If the connector floats free on one end, delete it (click the line, then press Delete) and try again. Wait until the target shape highlights green before releasing.

help me connect two shapes in draw.io

Learn connector styling for UML

In UML diagrams, different arrow styles communicate different types of relationships between components.

Click the connector line you just created to select it.
Look at the Format panel on the right side of your screen.
Click the Style tab in the Format panel.
Find the line pattern option and change it from solid to dashed.

Your connector should now display as a dashed line. In UML, dashed lines represent dependency relationships.

With the connector still selected, find the connector end dropdown in the Style tab.
Try switching the arrowhead to an open triangle (used for inheritance in UML).
Switch it to a filled diamond (used for composition).
Switch it to a hollow diamond (used for aggregation).
Switch it to a simple open arrow (used for dependency).

What do these arrow styles mean?

Each arrowhead style communicates a specific type of relationship in UML diagrams:

Open triangle = inheritance ("is a" relationship).
Filled diamond = composition (part cannot exist without the whole).
Hollow diamond = aggregation (part can exist independently).
Simple open arrow = dependency (one component uses another).

You'll use these throughout your architecture diagrams to show how services relate to each other.

Don't see the Style tab?

The Format panel only shows the Style tab when you have a shape or connector selected. Click directly on the connector line to select it. You should see small blue squares appear on the line's endpoints.

If the entire right panel is missing, click Format in the top menu bar to toggle it back on.

help me find connector styling options in draw.io

Master layout techniques for clean diagrams

Clean alignment is what separates a sketch that impresses an interviewer from one that looks like a rough draft. draw.io has alignment and grouping tools that make this easy.

Select both shapes by pressing Cmd+A (macOS) or Ctrl+A (Windows) to select all.
In the Format panel on the right, click the Arrange tab.
Click Align Center (horizontal) to line up both shapes along their vertical centers.

Both rectangles should now be perfectly aligned horizontally.

With both shapes still selected, press Cmd+G (macOS) or Ctrl+G (Windows) to group them.
Try dragging the group around the canvas. Both shapes and their connector move together.

Why group shapes?

Grouping lets you treat related components as a single unit. In architecture diagrams, you'll group services that belong to the same layer so you can reposition an entire layer without breaking alignments.

Select everything on the canvas by pressing Cmd+A (macOS) or Ctrl+A (Windows).
Press Delete (or Backspace) to remove all practice shapes from the canvas.

Your canvas should now be completely empty. You have a clean slate ready for the real architecture diagram.

Still seeing shapes on the canvas?

If shapes remain after pressing Delete, they might not have been selected. Click an empty area of the canvas first to deselect, then press Cmd+A (macOS) or Ctrl+A (Windows) again to select all remaining shapes, then press Delete.

help me delete all shapes from my draw.io canvas

You now have the core draw.io skills you need. Next up, you'll put them to work building the high-level component diagram of Twitter's architecture.

Build the High-Level Component Diagram (Page 1)

With your draw.io workspace ready, it is time to build the first diagram that every system design interview starts with: the high-level component overview.

This diagram shows the full picture of Twitter's distributed architecture at a glance. It maps out every microservice, data store, and the Apache Kafka event backbone that ties them together. Interviewers expect you to start here before drilling into specific request flows.

In this step, get ready to:

Lay out five architectural layers from clients down to the event backbone.
Connect components with proper UML arrows and labels.
Color-code and annotate the diagram for interview clarity.

Lay out the five architectural layers top-to-bottom

System design diagrams follow a standard 5-layer layout from top to bottom: Client, Delivery, Application, Data, and Message Queue. This visual hierarchy mirrors how a request flows through the system.

Why the 5-layer layout?

Interviewers expect this top-to-bottom structure because it matches how data flows in a real distributed system. Clients sit at the top, requests travel downward through load balancers and services, and events fan out at the bottom.

Keeping to 10-12 components maximum on a single diagram ensures clarity under time pressure.

You will build each layer by dragging Component shapes from the UML shape library onto the canvas.

In the left panel, find the UML shape library and locate the Component shape (a rectangle with the small component icon in the top-right corner).
Drag a Component shape to the top-center of your canvas and double-click it to label it Mobile App.
Drag a second Component shape next to it and label it Web App.
These two shapes form your Client Layer at the top of the diagram.

Now build the remaining four layers below the Client Layer, spacing each row about 150px apart vertically.

Create the Delivery Layer below the clients. Drag two Component shapes and label them API Gateway and Load Balancer.
Create the Application Layer below the Delivery Layer. Drag six Component shapes in a row and label them: Tweet Service, Timeline Service, User Service, Search Service, Notification Service, and Media Service.
Create the Data Layer below the Application Layer. Drag four Component shapes and label them: Redis Cache, Tweets DB (NoSQL), User DB (SQL), and Feed Cache (Redis).
Create the Event Backbone at the bottom. Drag one large Component shape and label it Apache Kafka. Make it wider than the other shapes so it spans much of the Application Layer above.
Double-click inside the Kafka shape and add topic labels on separate lines: tweet.created, user.followed, tweet.liked.

Your canvas should now show five distinct horizontal rows of components, reading top to bottom like a request flowing through the system.

What are these Kafka topics?

Each topic represents a category of event that Kafka processes. When a user publishes a tweet, the Tweet Service emits an event to the tweet.created topic. Downstream services (fan-out workers, search indexers, notification service) subscribe to these topics independently.

Twitter processes approximately 400 billion events per day through Kafka. The topic-based model lets each consumer read at its own pace without blocking others.

Shapes overlapping or misaligned?

Select all shapes in a layer by dragging a selection box around them. In the Arrange tab of the Format panel on the right, click Align Center to line them up horizontally. Use Distribute Horizontally to space them evenly.

If shapes are too close together, resize by dragging their corner handles outward.

Still having trouble lining things up?

Connect components with proper UML notation

Arrows in a UML component diagram carry specific meaning. Solid arrows indicate direct dependencies, while dashed arrows indicate asynchronous or optional relationships. Labels on each arrow tell the interviewer which protocol or action the connection represents.

Start with the Client-to-Delivery connections. Hover over the Mobile App shape until blue arrow indicators appear on its edges.
Click and drag from a blue arrow indicator down to the API Gateway shape to create a connector.
Double-click the connector line to add a label. Type HTTPS/REST.
Repeat for Web App down to API Gateway, also labeled HTTPS/REST.

Now connect the API Gateway down to each service in the Application Layer.

Draw a solid arrow from API Gateway to each of the six services.
Label each of these arrows gRPC (this is how Twitter's services communicate internally).

Next, connect the services to Kafka and the data stores.

Draw a solid arrow from Tweet Service down to the Apache Kafka shape. Label it publish.
Draw dashed arrows from Apache Kafka up to Timeline Service, Notification Service, and Search Service. Label each subscribe.
To make a connector dashed: select it, open the Style tab in the Format panel on the right, and change the line pattern from solid to dashed.
Draw solid arrows from services to their data stores: Tweet Service to Tweets DB (NoSQL), User Service to User DB (SQL), Timeline Service to Feed Cache (Redis), and Search Service to Redis Cache.

Finally, add the UML "lollipop" interface notation where services expose APIs to each other.

In the UML shape library, find the Provided Interface shape (a small circle on a line, sometimes called a "lollipop").
Attach a Provided Interface to the edge of Tweet Service and User Service to indicate they expose APIs that other services consume.

Why solid arrows for publish and dashed for subscribe?

The solid arrow from Tweet Service to Kafka represents a synchronous, intentional action: the service actively publishes an event. The dashed arrows from Kafka to consumers represent asynchronous subscriptions. Consumers read at their own pace without blocking the publisher.

This visual distinction immediately communicates to an interviewer that the write path is decoupled from downstream processing.

Connectors not attaching to shapes?

Make sure you start the connector from a blue arrow indicator on the shape's edge, not from the shape's interior. If the connector is floating (no blue dot at its endpoints), drag the endpoint until it snaps to the target shape's border.

If arrows keep connecting to the wrong edge, zoom in with Cmd + (macOS) or Ctrl + (Windows) for more precise placement.

Need help with connector attachment?

Add styling and annotations for interview clarity

Color-coding and annotations transform a raw diagram into something you can present confidently under interview pressure. Colors help the interviewer instantly identify which layer a component belongs to, and annotations preemptively answer the "why" questions they will ask.

Select both Client Layer shapes (Mobile App and Web App). In the Style tab of the Format panel, click the fill color swatch and choose a light blue.
Select all six Application Layer services. Set their fill color to green.
Select the Apache Kafka shape. Set its fill color to orange.
Select all four Data Layer shapes. Set their fill color to gray.

Now add a title and design-decision annotations.

Double-click an empty area in the top-left corner of the canvas to create a text label. Type Twitter High-Level Architecture - Component Diagram.
In the UML shape library, find the Note shape (a rectangle with a folded corner).
Drag a Note shape near the Apache Kafka component. Double-click it and type: Kafka decouples write path from fan-out.
Drag a second Note shape near Feed Cache (Redis). Type: Redis pre-computes timelines for O(1) reads.
Save your diagram with Cmd+S (macOS) or Ctrl+S (Windows).

Why annotate design decisions directly on the diagram?

In a system design interview, you narrate as you draw. Annotations act as talking-point reminders. When the interviewer asks "why Kafka here?" you can point directly at the note and explain that Kafka decouples the synchronous write path from the asynchronous fan-out to millions of followers.

These notes also demonstrate that you understand the trade-offs, not just the architecture.

Your completed Page 1 should show five clearly separated layers with color-coded components, labeled connectors showing data flow direction, and annotation notes highlighting key decisions.

Diagram looking cluttered?

If connector labels overlap, click a label and drag it along the connector line to reposition it. You can also click the label and use the Arrange tab to adjust its offset from the line.

If the whole diagram feels cramped, select all shapes with Cmd+A (macOS) or Ctrl+A (Windows) and drag outward from the center to increase spacing between layers.

My diagram looks messy and hard to read. How can I clean it up?

Your high-level component diagram is complete. Next up, you will zoom into the first critical flow: what happens when a user publishes a tweet, and how Kafka fans that tweet out to millions of followers.

Build the Tweet Publish Sequence Diagram (Page 2)

Your component diagram gives the interviewer a bird's-eye view of Twitter's architecture. Now it's time to zoom in on a specific flow and show exactly what happens when a user publishes a tweet.

A UML sequence diagram models the request lifecycle through services over time. In interviews, this is how you answer "walk me through what happens when a user does X." You'll build one showing both the synchronous write path (the user waits for this) and the asynchronous Kafka fan-out (background work the user never sees).

In this step, get ready to:

Create a new diagram page for the tweet publish sequence.
Draw the synchronous write path with proper UML message notation.
Model the asynchronous Kafka fan-out with a loop fragment.

Create a new diagram page and set up lifelines

Sequence diagrams live on their own page so you can present each flow independently during an interview. Each vertical dashed line (called a lifeline) represents one participant in the interaction.

At the bottom of the canvas, click the + button to add a new page.
Double-click the new page tab and rename it to Sequence - Tweet Publish.
In the left panel, expand the UML 2.5 shape library.
Drag a Lifeline shape onto the canvas.
Double-click it and label it Client.
Drag six more Lifeline shapes and space them evenly to the right of Client.
Label them left to right: API Gateway, Tweet Service, Tweets DB, Kafka (tweet.created topic), Fan-out Workers, Feed Cache (Redis).

You should see seven evenly spaced lifelines with dashed vertical lines extending downward.

What are lifelines?

Each lifeline represents a system participant (a service, database, or queue) in the interaction. The dashed vertical line shows that participant's existence over time. Messages flow horizontally between lifelines, and time flows top to bottom.

Don't see UML 2.5 shapes?

Click + More Shapes at the bottom of the left panel. Scroll to the Software section and check UML 2.5. Click Apply.

Still having trouble? Help me find the UML 2.5 Lifeline shape in draw.io.

Draw the synchronous write path messages

The synchronous path is what the user waits for. Every message here must complete before the user gets their "tweet posted" confirmation. You'll use solid arrows with filled arrowheads for these synchronous calls.

Hover over the Client lifeline until a blue arrow indicator appears.
Click and drag from that blue arrow to the API Gateway lifeline to create a connector.
Double-click the connector and label it POST /tweets {content, auth_token}.
Select the connector. In the Style tab of the Format panel on the right, ensure the line is solid and the arrowhead is a filled triangle (this indicates a synchronous message in UML).

Continue drawing solid arrows for the remaining synchronous messages, moving down the diagram. Each new message should be placed below the previous one.

Draw message 2 from API Gateway to Tweet Service. Label it validateAndCreate(tweet).
Draw message 3 from Tweet Service to Tweets DB. Label it persist(tweet_id, user_id, content, timestamp).
Draw message 4 as a return (dashed arrow) from Tweets DB back to Tweet Service. Label it ack (durable write confirmed). Change this connector's line pattern to dashed in the Style tab.
Draw message 5 from Tweet Service to Kafka (tweet.created topic). Label it publish(NewTweetEvent: tweet_id, author_id, timestamp).
Draw message 6 as a return (dashed arrow) from Tweet Service back to API Gateway. Label it 201 Created {tweet}.
Draw message 7 as a return (dashed arrow) from API Gateway back to Client. Label it 200 OK {tweet object}.

Now add activation bars to show when each participant is actively processing.

From the UML 2.5 shapes, drag a narrow rectangle (activation bar) onto each lifeline where that participant is active. For example, place one on Tweet Service spanning from message 2 down to message 6.
Add activation bars to API Gateway (messages 1-7), Tweets DB (messages 3-4), and Kafka (tweet.created topic) (message 5).

What do activation bars show?

Activation bars are the narrow rectangles on top of lifelines. They indicate the period during which a participant is performing an action or waiting for a response. In interviews, they make it visually obvious which services are involved at each stage of the flow.

Return arrows use dashed lines

In UML sequence diagrams, return messages (responses going back to the caller) use dashed arrows with open arrowheads. Forward calls use solid arrows with filled arrowheads. This visual distinction helps interviewers instantly see the difference between requests and responses.

Arrows connecting to the wrong lifeline?

Make sure you start dragging from a blue arrow indicator on the source lifeline. If the arrow attaches to the wrong target, click the arrow endpoint and drag it to the correct lifeline until it snaps in place.

If your messages appear at the same vertical level instead of stacking downward, drag each new message's start point lower on the source lifeline. Help me arrange my sequence diagram messages in draw.io.

Draw the asynchronous fan-out path

The user already has their response by now. Everything below this point happens in the background. Kafka consumers pick up the event and distribute the tweet to every follower's timeline cache. This is the fan-out-on-write pattern.

Below message 7, draw a horizontal dashed line across the full width of the diagram. You can use a simple line shape and set its pattern to dashed.
Double-click the line and label it -- async boundary --.

This visual separator tells the interviewer everything above is latency the user experiences, and everything below happens after they've already received their response.

Below the async boundary, draw message 8 from Kafka (tweet.created topic) to Fan-out Workers. Label it consume(NewTweetEvent).
Select this connector. In the Style tab, change the arrowhead to an open (unfilled) triangle. This indicates an asynchronous message in UML.
Draw message 9 as a self-call on Fan-out Workers. Drag from the Fan-out Workers lifeline back to itself, creating a small loop arrow. Label it lookupFollowers(author_id).
Draw message 10 from Fan-out Workers to Feed Cache (Redis). Label it LPUSH follower_timeline tweet_id.

Now wrap message 10 in a UML loop fragment to show it repeats for every follower.

From the UML 2.5 shapes, find the Combined Fragment shape (a rectangle with a label tab in the top-left corner).
Drag it onto the canvas and resize it to enclose message 10 (the LPUSH arrow and both lifelines involved).
Double-click the label tab in the top-left corner of the fragment and type loop [for each follower].

Finally, add an annotation note to explain the timing to your interviewer.

From the UML shape library, drag a Note shape onto the right side of the diagram.
Double-click and type: ~100-200ms for user response. Fan-out happens in background via Kafka consumers..
Draw a dashed line from the note to the async boundary line to connect the annotation visually.

Save your diagram with Cmd+S (macOS) or Ctrl+S (Windows).

Why separate sync from async?

This separation is exactly what interviewers look for. The synchronous path (about 100-200ms) is what determines the user experience. The async fan-out can take seconds or even minutes for celebrities with millions of followers, but the user doesn't wait for it.

Kafka makes this possible by acting as a durable buffer between the write path and the fan-out workers. Even if the fan-out workers fall behind, no tweets are lost.

Self-call arrow not looping correctly?

To draw a self-call, start the arrow from the right side of the Fan-out Workers activation bar and curve it back to the same lifeline slightly lower. If draw.io creates a straight line instead, try manually adding a waypoint by right-clicking the connector and selecting Add Waypoint. Drag the waypoint to the right to create the loop shape.

Need more help? How do I draw a self-call message on a sequence diagram in draw.io?.

Your tweet publish sequence diagram is complete. Next up, you'll build the companion diagram showing how timelines are read back. This involves Twitter's clever hybrid fan-out strategy for handling celebrities.

Build the Hybrid Fan-out Read Path Sequence Diagram (Page 3)

Your tweet publish sequence diagram shows how tweets get written and fanned out to followers. But what happens when a user opens their timeline to read?

This is where Twitter's architecture gets interesting. Pure fan-out-on-write breaks for celebrities with millions of followers (imagine writing to 100 million caches every time they tweet). In this step, you will model the hybrid read path that solves this "celebrity problem" using a mix of pre-computed feeds and on-demand merging.

In this step, get ready to:

Create a new diagram page with lifelines for the timeline read path.
Draw messages showing the hybrid fan-out merge flow with an alt fragment.
Add trade-off annotations that demonstrate interview-ready reasoning.

Set up the timeline read scenario

This sequence diagram models what happens when a user requests their home timeline. The key insight is that Twitter uses two different strategies depending on whether the tweet author is a regular user or a celebrity.

Click the + button at the bottom of the canvas to add a new page.
Double-click the new page tab and rename it to Sequence - Timeline Read (Hybrid).
From the UML 2.5 shape library in the left panel, drag six Lifeline shapes onto the canvas.
Label the lifelines from left to right: Client, API Gateway, Timeline Service, Feed Cache (Redis), Celebrity Tweet Store, Tweets DB.
Space them evenly across the canvas with their dashed vertical lines extending downward.
From the UML shape library, drag a Note shape to the top-right area of the canvas.
Double-click the note and type: Hybrid strategy: fan-out-on-write for regular users (< 10K followers), fan-out-on-read for celebrities.

What is the celebrity problem?

When a celebrity with 50 million followers tweets, fan-out-on-write means pushing that tweet ID into 50 million individual timeline caches. That creates massive write amplification and delays.

The solution is hybrid: regular users (under ~10K followers) still use fan-out-on-write for fast reads. Celebrity tweets are fetched and merged on-demand when a follower requests their timeline. The industry standard threshold is approximately 5K to 10K followers.

Your canvas should now show six evenly-spaced lifelines with a note in the top-right corner explaining the hybrid strategy.

Don't see the Note shape?

The Note shape lives in the UML library (not UML 2.5). If you don't see it, click More Shapes at the bottom of the left panel, scroll to Software, and ensure both UML and UML 2.5 are checked.

help me find the UML Note shape in draw.io

Draw the hybrid merge flow

This sequence has two parallel data fetches that merge together. The Timeline Service pulls pre-computed tweet IDs from the Feed Cache for regular users, then separately fetches recent celebrity tweets, merges both lists, and hydrates them with full tweet content.

Draw a solid arrow (filled arrowhead) from Client to API Gateway and label it GET /home_timeline.
Draw a solid arrow from API Gateway to Timeline Service and label it getTimeline(user_id).
Draw a solid arrow from Timeline Service to Feed Cache (Redis) and label it LRANGE user:{id}:feed 0 50.
Draw a dashed return arrow from Feed Cache (Redis) back to Timeline Service and label it List<tweet_ids> (regular users tweets).
Draw a solid arrow from Timeline Service to Celebrity Tweet Store and label it getRecentTweets(celebrity_ids_user_follows).
Draw a dashed return arrow from Celebrity Tweet Store back to Timeline Service and label it List<tweet_ids> (celebrity tweets).
Draw a self-call arrow on Timeline Service (an arrow that loops back to the same lifeline) and label it merge + rank by timestamp.
Draw a solid arrow from Timeline Service to Tweets DB and label it hydrate(merged_tweet_ids).
Draw dashed return arrows all the way back from Tweets DB to Timeline Service, then Timeline Service to API Gateway, then API Gateway to Client with the assembled timeline.

Now add the alt UML fragment to show the two strategies visually.

From the UML 2.5 shape library, find the Combined Fragment shape (a rectangle with a label tab in the top-left corner).
Drag it onto the canvas and resize it to surround messages 3 through 6 (the Feed Cache request/response and the Celebrity Tweet Store request/response).
Label the fragment tab alt by double-clicking it.
Draw a horizontal dashed line across the middle of the fragment to create two compartments.
In the top compartment (containing the Feed Cache messages), add a text label: [regular users: pre-computed].
In the bottom compartment (containing the Celebrity Tweet Store messages), add a text label: [celebrities: computed on read].

What is an alt fragment?

In UML sequence diagrams, an alt (alternative) fragment shows conditional branching. Each compartment represents a different path based on the guard condition in brackets.

Here, the two compartments show that both strategies execute in parallel for a single timeline request. The Timeline Service fetches from the pre-computed cache AND from the celebrity store, then merges the results.

Your diagram should now show the complete message flow with the alt fragment clearly separating the two fan-out strategies.

Arrows connecting to the wrong lifeline?

Make sure you are dragging from the blue connection point on the source lifeline's activation bar. If an arrow snaps to the wrong target, click the arrow endpoint and drag it to the correct lifeline. You can also select the arrow and check its start/end points in the Arrange tab.

help me fix connector endpoints on my draw.io sequence diagram

Annotate trade-offs for interview discussion

In a system design interview, the diagram alone is not enough. Interviewers want to see that you understand WHY the hybrid approach exists and what each strategy trades off. Adding annotation notes to your diagram gives you built-in talking points.

Drag a Note shape from the UML library and place it near the top compartment of your alt fragment (the Feed Cache side).
Double-click the note and type: Fan-out-on-write: fast reads (O(1) from Redis), but write amplification for celebrities with millions of followers.
Drag a second Note shape and place it near the bottom compartment (the Celebrity Tweet Store side).
Double-click and type: Fan-out-on-read: no write amplification, but slower reads requiring merge at query time. Threshold: ~10K followers.
Draw a dashed line from each note to the relevant compartment of the alt fragment to visually connect the annotation to its context.
Save your diagram with Cmd+S (macOS) or Ctrl+S (Windows).

Why do these annotations matter in interviews?

When you present this diagram, the annotations become your script. You can point to the top compartment and say "regular users get O(1) reads from pre-computed Redis caches." Then point to the bottom and explain the celebrity problem.

This demonstrates that you can reason about real trade-offs, not just draw boxes. The ~10K follower threshold is an industry-standard number that shows you have studied production systems.

Your Page 3 should now have six lifelines, nine messages (including the self-call and return chain), an alt fragment with two labeled compartments, and two trade-off annotation notes.

You now have three pages telling a complete story: the architecture overview, the write path, and the read path. Next up, you will map all of these services onto real infrastructure with a deployment diagram that shows multi-region scaling, sharding, and replication.

Build the Deployment Diagram and Polish for Interviews (Page 4)

Your sequence diagrams now tell the story of how data flows through Twitter's system. An interviewer's natural follow-up question is: "Where does all of this actually run?" That's what a deployment diagram answers.

In this step, you will map every service to its physical infrastructure. You will show multi-region replication, cluster sizing, and capacity numbers that prove you can reason about real-world scale.

In this step, get ready to:

Create a UML deployment diagram with multi-region infrastructure nodes.
Add capacity annotations using UML stereotypes.
Polish all four pages for naming consistency, title blocks, and cross-page links.

Create the deployment diagram showing infrastructure

A deployment diagram maps logical services to the physical (or cloud) infrastructure they run on. In UML, infrastructure targets are drawn as "Node" shapes, which are 3D boxes that can nest inside each other to show containment.

Click the + button at the bottom of the canvas to add a new page.
Double-click the new page tab and rename it to Deployment Diagram.

Now set up the top-level regional structure.

From the UML 2.5 shape library in the left panel, find the Node shape (a 3D box).
Drag a large Node onto the left side of the canvas and label it Region US-East.
Drag a second large Node onto the right side and label it Region EU-West.
Make both region nodes large enough to contain several nested nodes inside them.

Why two regions?

Multi-region deployment reduces latency for global users and provides fault tolerance. If US-East goes down, EU-West can still serve traffic. Interviewers expect you to mention this trade-off when discussing availability.

Next, add the compute layer inside each region.

Inside the Region US-East node, drag a medium-sized Node and label it Kubernetes Cluster.
Inside the Kubernetes Cluster node, drag three smaller Nodes and label them: Tweet Service Pods (x3), Timeline Service Pods (x5), and API Gateway (Nginx).
Outside the Kubernetes Cluster but still inside the Region US-East node, drag four more Nodes and label them: Kafka Cluster (3 brokers, RF=3), Redis Cluster (6 nodes, 3 primary + 3 replica), PostgreSQL (User DB, leader-follower), and Cassandra (Tweets DB, 5 nodes).
Repeat this exact same structure inside Region EU-West. You can select all nodes inside US-East (drag a selection box), duplicate them with Cmd+D, and drag the copies into the EU-West region.

Finally, add the CDN and cross-region connections.

Above both region nodes, drag a Node and label it CDN (Cloudflare).
Draw connectors from the CDN node down to the API Gateway inside each region.
Draw a bidirectional arrow between the two region nodes. Double-click the arrow to label it Cross-region replication.
To make the arrow bidirectional, select it, then in the Style tab of the Format panel, set both the source and target connector ends to open arrows.

Keep nesting visually clear

If your nested nodes are hard to distinguish from their containers, give the outer nodes a light background fill color. For example, light blue for the region nodes and white for the Kubernetes cluster. This makes the containment hierarchy obvious at a glance.

Add scaling annotations and capacity numbers

Raw boxes without numbers won't impress an interviewer. Adding concrete capacity specifications shows you can reason about real infrastructure sizing.

From the UML shape library, drag a Note shape (rectangle with a folded corner) and place it near the Kafka Cluster node in US-East.
Double-click the note and type the following deployment specification:

<<deployment spec>>
3 brokers
partitions=12 per topic
replication factor=3
retention=7 days

Draw a dashed connector from this note to the Kafka Cluster node.
Add a second Note near Redis Cluster with this specification:

<<deployment spec>>
6 nodes
256GB RAM each
LRU eviction

Draw a dashed connector from this note to the Redis Cluster node.
Add a third Note near Cassandra with this specification:

<<deployment spec>>
5 nodes
consistent hashing
partition key=user_id

Draw a dashed connector from this note to the Cassandra node.
To make the connectors dashed, select each one and change the Pattern to dashed in the Style tab.

Why these specific numbers?

Twitter processes approximately 400 billion events per day through Kafka. A replication factor of 3 ensures no data loss if a broker goes down. Redis uses LRU (Least Recently Used) eviction to keep only the most active timelines in memory.

Cassandra uses consistent hashing with user_id as the partition key so all tweets from the same user land on the same node. This makes per-user queries fast.

Polish all four pages for interview readiness

A polished diagram set signals professionalism. Interviewers notice when labels are inconsistent or pages feel disconnected. This final pass ties everything together into a cohesive presentation.

Click through all four page tabs and verify that service names match exactly across diagrams. For example, check that Page 1 says "Tweet Service" and Pages 2 and 4 also say "Tweet Service" (not "TweetService" or "Tweet Svc").
On each page, add a title block in the top-left corner. Drag a text label (double-click empty canvas to create one) and type the diagram title.

Use these titles for each page:

Page 1: Twitter High-Level Architecture - Component Diagram.
Page 2: Tweet Publish Flow - Sequence Diagram.
Page 3: Timeline Read (Hybrid Fan-out) - Sequence Diagram.
Page 4: Infrastructure - Deployment Diagram.

Now add cross-page links so you can navigate between diagrams during an interview presentation.

Navigate to Page 1 (your component diagram).
Right-click the "Tweet Service" component shape.
Select Edit Link from the context menu.
In the link dialog, click the page selector and choose the "Sequence - Tweet Publish" page. Click Apply.
Right-click the "Timeline Service" shape and link it to the "Sequence - Timeline Read (Hybrid)" page using the same method.

What do these links do?

Linked shapes become clickable in the editor and in exported interactive formats. During an interview, you can click a service on your overview diagram to jump directly to its detailed sequence diagram. This makes your presentation flow naturally from high-level to specific.

Finally, save your work and export the full diagram set.

Press Cmd+S (macOS) or Ctrl+S (Windows) to save your twitter-architecture.drawio file.
Click File in the top menu bar.
Select Export as, then choose PDF.
In the export dialog, make sure All Pages is selected.
Click Export and save the PDF to your computer.

You should now have a twitter-architecture.pdf containing all four pages of your architecture diagram, ready to share or reference in interviews.

PDF only shows one page?

Make sure you selected "All Pages" in the export dialog, not "Current Page." If the option does not appear, try File > Export as > PDF again and look for a checkbox or dropdown labeled "Pages" before clicking Export.

Help me export all pages to PDF in draw.io

How to present these diagrams in an interview

Start with Page 1 (component overview) and talk through the layers top to bottom. When the interviewer asks "walk me through what happens when a user tweets," switch to Page 2. When they ask about reads or the celebrity problem, switch to Page 3. Save Page 4 for scaling questions.

This progression mirrors the recommended system design interview time allocation: core design first (10-20 minutes), then interfaces and data flow (20-40 minutes), then scaling and reliability (40-60 minutes).

Secret mission

Add a Notification and Trending Topics Activity Diagram (Page 5)

You've modeled the core tweet publish and read paths. But Twitter's Kafka backbone powers much more than timelines. Can you model two additional real-time pipelines using a UML activity diagram with swimlanes?

Clean Up Your Resources

This project runs entirely in your browser with files saved locally on your device. There are no ongoing costs or cloud resources to manage.

Resources you used:

twitter-architecture.drawio file saved on your device.
draw.io web app (app.diagrams.net) open in your browser.
Exported PDF file (if you completed the final export step).

Keep everything running

No action needed. Choose this if you plan to keep iterating on your diagrams or want to reference them during interview prep.

Your twitter-architecture.drawio file stays on your device wherever you saved it.
You can reopen it anytime at app.diagrams.net by choosing File > Open From > Device.
Bookmark app.diagrams.net for quick access in future interview prep sessions.

Pause - I'll come back to this later

Close the browser tab to free up memory. Your diagram file is already saved locally.

Press Cmd+S in draw.io to make sure your latest changes are saved.
Close the draw.io browser tab.
Remember where you saved your twitter-architecture.drawio file so you can find it later.

Delete - I don't want to use this again

Remove all project files from your device to start fresh.

Close the draw.io browser tab.
Locate your twitter-architecture.drawio file in Finder (macOS) or File Explorer (Windows) and move it to the Trash.
Delete any exported PDF files you created from the diagram.
Empty your Trash to permanently remove the files.

Nice Work!

Nice work! You just built a professional, interview-ready set of UML architecture diagrams modeling Twitter's distributed system from scratch in draw.io.

Here's what you learned:

Built a complete 4-page UML architecture diagram of Twitter's distributed system in draw.io, covering component, sequence, and deployment diagram types.
Modeled real distributed systems patterns like Kafka-driven fan-out, the hybrid caching strategy, and the celebrity problem using proper UML notation.
Gained fluency with draw.io's UML tools including shape libraries, connector styling, multi-page navigation, and grouping to rapidly sketch architecture diagrams under interview time pressure.
Added a UML activity diagram with swimlanes modeling notification delivery and trending topics pipelines as a Secret Mission extension.

Ready to quiz yourself?