Scaling Mailbox - From 0 to One Million Users in 6 Weeks and 100 Million Messages Per Day - High Scalability -

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

• Low-Level Design Practice · 10 minChat applicationUsers, conversations and messages: delivery states, group chats and notifying clients, modelled as classes rather than infrastructure.Read hereClose

  The problem

  Users send text messages one-to-one or in groups. The app shows who is online, message status (sent, delivered, read) and notifies offline users. This lesson is about the classes; the infrastructure view (WebSockets, storage at scale) is in the chat-system lesson of the classic designs course.

  Entities

  100%

  Figure SDA-LLD-14-1 · Chat classes · © forcsguy.com

  A conversation has a type (direct or group) and participants. A message belongs to one conversation and has one receipt per recipient.

  Sending a message

  100%

  Figure SDA-LLD-14-2 · Sending a message · © forcsguy.com

  type Status = "SENT" | "DELIVERED" | "READ";
  class Conversation {
    private subscribers = new Map<string, (m: Message) => void>();
    constructor(readonly id: string, readonly members: string[]) {}
  
    subscribe(userId: string, fn: (m: Message) => void) { this.subscribers.set(userId, fn); return () => this.subscribers.delete(userId); }
  
    send(from: string, text: string): Message {
      if (!this.members.includes(from)) throw new Error("not a member");
      const m = new Message(newId(), this.id, from, text);
      m.receipts = Object.fromEntries(this.members.filter(u => u !== from).map(u => [u, "SENT" as Status]));
      store.save(m);                                         // persist first
      for (const [u, fn] of this.subscribers) if (u !== from) fn(m);   // push to online users
      return m;                                              // offline users get it when they reconnect, or by push notification
    }
  }
  

  Offline users and ordering

  • Offline users receive messages on reconnect by asking for everything after the last message id they have, and may get a push notification.
  • Order within a conversation comes from a server-assigned, increasing message id.
  • Read receipts are updates to the per-recipient receipt, then aggregated for the sender (in a group, "read by 3 of 5").

  Design notes

  • Observer decouples the conversation from how clients are connected.
  • Group size matters: a small group can notify each member directly; very large channels need a different fan-out approach.
  • Presence (online, last seen) is a separate component with its own throttled updates.
  • Privacy: block lists, muted conversations, and "delete for everyone" are policies checked before delivery.
  • Extensions: media messages (store files elsewhere, send a reference), replies, reactions, end-to-end encryption.

  Real-world reading

  Related reading

  • RFC 6455: The WebSocket ProtocolIETFDocumentation
  • Scaling Real-time Infrastructure at Alibaba for Global Shopping Holiday - Xiaowei Jiang, Senior Director at AlibabaAlibaba engineers · AlibabaCase Studies
  • 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
  • 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

  • Scaling Live Videos to a Billion Users at Facebook - Sachin Kulkarni, Director of Engineering at FacebookFacebookYouTube
  • MDN: WebSockets APIMDN Contributors · MozillaDocumentation
  • The WhatsApp Architecture Facebook Bought for $19BHigh ScalabilityCase Studies
  • Infrastructure to Run User Forecasts at SpotifySpotify engineers · SpotifyCase Studies
  • Data Infrastructure at LinkedInLinkedIn engineers · LinkedInCase Studies
  • Real-Time Data Warehouse with MemSQL on Cisco UCSCisco engineers · CiscoCase Studies

  Open this lesson with its quiz and exercise