The Architecture Twitter Uses to Deal with 150M Active Users, 300K QPS, a 22 MB/S Firehose, and Send Tweets in Under 5 Seconds

Ideas you will meet

Distributed Systems

Consensus, time, failure and the fundamentals of scale-out.

What we already know about this

Our own lessons on these ideas. Read them here before you start, so it makes sense.

• System Design Foundations · 9 minWhat system design is, and how to approach itA repeatable way to turn a vague request like 'design Twitter' into a concrete, defensible architecture.Read hereClose

  Design is choosing under constraints

  A system is the set of servers, databases, caches, queues and networks that together deliver a product. System design is the work of deciding which pieces you need, how they connect, and what you give up with each choice.

  It matters because code that works for ten users often fails at ten million. Not because the code is wrong, but because new problems appear with scale: one machine is no longer enough, networks drop messages, disks fail, and two users change the same data at once.

  A five-step approach

  You can use the same sequence for a real project or an interview.

  100%

  Figure SDA-FND-01-1 · Five-step design approach · © forcsguy.com

  1. Clarify requirements. Separate what the system must do (functional) from how well it must do it (non-functional). Ask until the problem is small enough to solve.

  • Functional: "users can post a photo and follow other users"
  • Non-functional: "feeds load in under 300 ms", "uploads are never lost", "the site stays up if one data center fails"

  2. Estimate scale. A rough guess of requests per second and data size tells you whether one database is enough or you need to split data across many. Lesson 3 covers this.

  3. Sketch the high-level design. Boxes and arrows: clients, a load balancer, application servers, a database, maybe a cache and a queue. Keep it simple first.

  4. Go deep on the hard parts. Pick the two or three places where the problem is genuinely difficult, such as how a feed is built, and design those carefully.

  5. Check bottlenecks and failures. Ask what breaks first as traffic grows, and what happens when each component fails. Fix single points of failure.

  Requirements: the part people skip

  Compare these two requests:

  Vague	Useful
  "Build a chat app"	"1-to-1 and group chat for 10 million daily users, messages delivered in under a second, history kept forever, no message ever lost"

  The second one tells you that you need persistent storage, a way to push messages to online users and a durability guarantee. The first tells you nothing.

  Trade-offs are the whole game

  Every decision has a cost:

  • A cache makes reads fast but can serve stale data.
  • Replicating data across data centers survives failures but makes writes slower or harder to keep consistent.
  • Splitting an application into microservices lets teams work independently but adds network calls that can fail.

  State the cost whenever you state a choice: "I would use a cache here, accepting that a user may see data up to a minute old, because reads outnumber writes 100 to 1."

  Common mistakes

  • Naming technologies before understanding the problem ("we will use Kafka")
  • Designing for a billion users when you have a thousand. Plan for roughly 10 times your expected scale, not 1000 times.
  • Ignoring failure. Networks and machines fail constantly at scale, so failure handling is part of the design, not an add-on.
  • Never writing down assumptions. When estimates are wrong, the design built on them is wrong too.

  In the next lesson we start with the simplest question: how does one server become many?

  Real-world reading

  Related reading

  • The Architecture Twitter Uses to Deal with 150M Active Users, 300K QPS, a 22 MB/S Firehose, and Send Tweets in Under 5 SecondsHigh Scalability engineers · High ScalabilityCase Studies
  • LISA '10 - Operations at Twitter: Scaling Beyond 100 Million UsersYouTubeYouTube
  • Scaling Load Balancing Infra to Support 1.3 Billion Users at Facebook - Patrick Shuff, Production Engineer at FacebookFacebookYouTube
  • Scaling Mailbox - From 0 to One Million Users in 6 Weeks and 100 Million Messages Per Day - High Scalability -High Scalability engineers · High ScalabilityCase Studies

  Show 6 moreShow fewer

  • Designing Data-Intensive ApplicationsMartin Kleppmann · O'ReillyBooks
  • Azure Architecture CenterMicrosoft · Microsoft AzureDocumentation
  • Instagram Architecture: 14 Million users, Terabytes of Photos, 100s of Instances, Dozens of Technologies - High Scalability -High Scalability engineers · High ScalabilityCase Studies
  • How Discord Scaled Elixir to 5,000,000 Concurrent UsersDiscordCase Studies
  • Designing a Microservices Architecture for FailureRisingstack engineers · RisingstackCase Studies
  • Spotify EngineeringSpotify engineers · SpotifyBlogs

  Open this lesson with its quiz and exercise

• System Design Foundations · 9 minBack-of-the-envelope estimationQuick arithmetic that tells you whether you need one server or a thousand, and which resource will run out first.Read hereClose

  Why estimate at all

  You do not need exact numbers. You need to know the order of magnitude: is it 100 requests per second or 100,000? Is the data 10 GB or 10 PB? Those answers change the architecture completely, and you can get them with simple arithmetic.

  Numbers to remember

  Powers of two for sizes:

  Unit	Approx. size
  1 KB	a thousand bytes
  1 MB	a million bytes
  1 GB	a billion bytes
  1 TB	a trillion bytes
  1 PB	a thousand TB

  Time: one day is about 86,400 seconds, which we round to 100,000 (10^5) to make mental maths easy.

  Rough latencies (the exact values change with hardware, the ratios matter):

  Operation	About
  Read from memory	100 ns
  Read 1 MB sequentially from memory	tens of microseconds
  SSD random read	100 microseconds
  Round trip inside one data center	0.5 ms
  Disk seek	10 ms
  Round trip across continents	100 to 150 ms

  Two lessons fall out of this table: memory beats disk by orders of magnitude, and crossing a network or an ocean is expensive, so avoid unnecessary round trips.

  A method

  1. Start from users: daily active users (DAU).
  2. Actions per user per day, giving total requests per day.
  3. Divide by 100,000 for average requests per second (QPS).
  4. Multiply by 2 to 5 for peak QPS.
  5. Size per item times items per day gives storage per day; multiply by retention and replication.

  The method as a picture

  100%

  Figure SDA-FND-03-1 · From users to requests and storage · © forcsguy.com

  Worked example: a short-link service

  • 100 million new links per month.
  • Reads outnumber writes 10 to 1.

  Writes per second: 100,000,000 / (30 x 86,400) is about 40 per second. Reads: about 400 per second. Peak maybe 2,000 reads per second.

  Storage: each record is about 500 bytes (the short key, the long URL, a date). 100 million per month x 12 months x 5 years = 6 billion records x 500 bytes = 3 TB. Easily one modern database over a few years, with replicas for safety.

  What did we learn? The write rate is tiny, reads are modest, and the whole data set is small. This is not a problem that needs exotic technology, so the design should be simple. That conclusion is the point of estimating.

  100%

  Figure SDA-FND-03-2 · Turning users into load and storage · © forcsguy.com

  Rules of thumb

  • Round aggressively. 86,400 becomes 100,000. 2.7 becomes 3.
  • Write units next to every number. Most mistakes are unit mistakes (bits versus bytes, MB versus GB).
  • State your assumptions. If someone disagrees with 10 requests per user, you can change one number and recompute.
  • Sanity check against reality. If your estimate says a small app needs a million servers, an assumption is off.

  Real-world reading

  Related reading

  • Cockroach Labs BlogCockroach Labs engineers · Cockroach LabsBlogs
  • The Architecture Twitter Uses to Deal with 150M Active Users, 300K QPS, a 22 MB/S Firehose, and Send Tweets in Under 5 SecondsHigh Scalability engineers · High ScalabilityCase Studies
  • AWS Database BlogAWS database teams · Amazon Web ServicesBlogs
  • LISA '10 - Operations at Twitter: Scaling Beyond 100 Million UsersYouTubeYouTube

  Show 6 moreShow fewer

  • Instagram Architecture: 14 Million users, Terabytes of Photos, 100s of Instances, Dozens of Technologies - High Scalability -High Scalability engineers · High ScalabilityCase Studies
  • Playfish's Social Gaming Architecture - 50 Million Monthly Users and Growing - High Scalability -High Scalability engineers · High ScalabilityCase Studies
  • CockroachDBCockroach Labs · GitHubGitHub
  • AWS Compute BlogAmazon Web Services engineers · Amazon Web ServicesBlogs
  • Yelp Engineering BlogYelp engineers · YelpBlogs
  • Telstra BlogTelstra engineers · TelstraBlogs

  Open this lesson with its quiz and exercise

• System Design Foundations · 9 minObservability and running a systemMetrics, logs and traces, how to define 'healthy' with SLOs, and how to ship changes without breaking things.Read hereClose

  You cannot fix what you cannot see

  A system you cannot observe is a system you cannot trust. Observability is the ability to understand what is happening inside from the outside. Three kinds of signal work together.

  Signal	What it is	Best for
  Metrics	Numbers over time (requests per second, error rate, CPU)	Dashboards, alerts, trends
  Logs	Timestamped records of events	Details of what happened
  Traces	The path of one request through many services	Finding where time is spent

  100%

  Figure SDA-FND-11-1 · From alert to root cause · © forcsguy.com

  What to measure

  A simple checklist, the four golden signals:

  1. Latency: how long requests take (use percentiles).
  2. Traffic: how much demand there is.
  3. Errors: how many requests fail.
  4. Saturation: how full the busiest resource is (CPU, memory, connections, disk, queue depth).

  Averages hide pain. If the average is 100 ms but p99 is 4 seconds, one user in a hundred is waiting four seconds, and with many requests per page that is most of your users sometimes.

  Defining healthy: SLIs, SLOs, error budgets

  • An SLI (indicator) is a measurement, like "fraction of requests answered successfully in under 300 ms".
  • An SLO (objective) is the target, like "99.9% over 30 days".
  • The error budget is what is left over: 0.1% of requests may fail. While there is budget, ship features; when it runs out, focus on reliability.

  Alert on symptoms users feel (error rate, latency) more than on causes (one machine's CPU). Page a human only for things that need action now.

  Ship changes safely

  Most outages come from changes. Reduce the risk:

  • Small, frequent releases are easier to understand and undo than big ones.
  • Canary release: send a few percent of traffic to the new version and watch the metrics before going wider.
  • Feature flags: deploy code turned off, then enable it gradually, and switch it off instantly if needed.
  • Blue-green: keep the old version running so you can switch back in seconds.
  • Backwards-compatible changes: database and API changes should work with both old and new code during rollout.
  • Fast rollback must be a rehearsed, boring button.

  When things go wrong

  Have an incident process: someone leads, someone communicates, mitigate first and investigate later. Afterwards write a blameless postmortem that asks "how did our system and process allow this?" rather than "who did this?". That is how reliability actually improves.

  A worked example: error budgets and burn rate

  Your service has an SLO of 99.9% of requests succeed over 30 days, and it serves 10 million requests a month.

  • Error budget: 0.1% of 10,000,000 = 10,000 failed requests may happen in the month before you break the promise.
  • Burn rate is how fast you spend it. A burn rate of 1 uses exactly the budget over 30 days. If 5% of requests are failing now, the error rate is 50 times the allowed 0.1%, a burn rate of 50: the whole month's budget is gone in 30 / 50 = 0.6 days, about 14 hours.
  • Alert on burn rate, not on a single bad minute. A common pattern watches two windows together: page someone if the burn rate over the last hour is above about 14 and the last 5 minutes agree (a fast burn: 2% of the monthly budget gone in an hour). Open a ticket for a slower burn, say rate above 6 over 6 hours. Two windows avoid paging for blips and avoid missing slow leaks.

  Why this beats "alert when error rate is above X": it ties alerts to what users were promised, it pages only when the budget is in danger, and it gives the team a rule for trade-offs: when the budget is healthy, ship faster; when it is nearly spent, slow down and fix reliability.

  100%

  Figure SDA-FND-11-2 · Alerting on how fast the error budget burns · © forcsguy.com

  Finding the cause with all three signals

  A worked investigation shows why you want metrics, traces and logs together.

  1. A metric alerts: the checkout success rate dropped and p99 latency rose. Metrics tell you that something is wrong and how bad, cheaply and over time.
  2. Narrow it down by dimension: break the metric down by region, version and endpoint. Only the new version in one region is affected, a strong hint it is a deploy.
  3. A trace shows where the time goes: one slow checkout request shows 4.8 of its 5 seconds in a call to the payment provider's tokenisation endpoint.
  4. Logs give the detail: filter logs by the trace id from that request and read the exact error: a timeout talking to a new tokenisation URL.
  5. Fix and verify: roll back the version, and watch the metric recover.

  100%

  Figure SDA-FND-11-3 · From an alert to a root cause · © forcsguy.com

  The glue is a correlation id (trace id) carried on every request and written into every log line, so you can jump from one signal to the others.

  Mistakes people make

  • Alerting on causes instead of symptoms. "CPU is 85%" may be fine; "users are seeing errors" never is. Page on symptoms users feel, and use cause metrics for diagnosis.
  • Averaging percentiles. The mean of two hosts' p99 is meaningless; merge distributions instead (see the t-digest lesson).
  • High-cardinality labels. A label such as user_id on a metric creates a new time series per user, which can multiply storage and cost by millions. Put such detail in logs or traces.
  • Logs without structure or ids. Free text is hard to query. Log JSON with a trace id, service and version.
  • Dashboards no one owns. A wall of graphs nobody reads is noise. Build a small dashboard per service around the golden signals: latency, traffic, errors and saturation.
  • No runbook. An alert that does not say what to check first wastes the first ten minutes of every incident.

  Try it yourself

  Run any test in the System Builder and read its charts as if they were production graphs: which signal moves first, and which part would you look at next? Build the search metrics lab to practise percentile maths, and read the t-digest lesson for how real systems summarise latency at scale.

  Real-world reading

  Related reading

  • The Site Reliability WorkbookGoogle SRE team · O'Reilly / GoogleBooks
  • Feature Toggles (aka Feature Flags)Pete Hodgson · Martin FowlerBlogs
  • InfluxData BlogInfluxData engineers · InfluxDataBlogs
  • MetricsDB: TimeSeries Database for storing metrics at TwitterTwitter engineers · TwitterCase Studies

  Show 6 moreShow fewer

  • The Architecture Twitter Uses to Deal with 150M Active Users, 300K QPS, a 22 MB/S Firehose, and Send Tweets in Under 5 SecondsHigh Scalability engineers · High ScalabilityCase Studies
  • Steady State: Always Put Logs on Separate DiskMicrosoft engineers · MicrosoftCase Studies
  • XCMetrics: All-in-One Tool for Tracking Xcode Build Metrics at SpotifySpotify engineers · SpotifyCase Studies
  • Honeycomb BlogHoneycomb engineers · HoneycombBlogs
  • BookKeeper: Distributed Log Storage at YahooYahoo engineers · YahooCase Studies
  • Analyzing V8 Garbage Collection Logs at AlibabaAlibaba engineers · AlibabaCase Studies

  Open this lesson with its quiz and exercise