Chapter 2: Scaling and Non-Functional Requirements – Turning Requirements into Metrics

With the foundational requirements from Chapter 1 firmly established, we shift our focus to the quantitative underpinnings that will make our messaging system not just functional, but formidable at scale. This chapter serves as the bridge between conceptual design and concrete engineering, where we quantify the tidal wave of messages, establish stringent performance benchmarks, and define the resilience pillars that ensure our platform stands unshaken against the storms of global usage. Imagine translating the abstract promises of seamless communication into hard numbers—the message volumes, response times, and failure tolerances that dictate our architectural choices. Without grounding our design in these metrics, we'd be constructing a house of cards rather than a fortress of reliability.

2. Traffic & Scaling Estimates

Let's translate the high-level assumptions from Chapter 1 into the concrete traffic patterns that will define our system's capacity needs. With 100 million daily active users, each exchanging an average of 50 messages per day, we begin to see the scale of our challenge. This isn't merely theoretical; these numbers will determine whether our infrastructure resembles a modest server farm or a sprawling data center empire.

At the heart of our traffic lies message ingress—the relentless inflow of writes as users send their communications. Multiplying 100 million users by 50 messages yields a breathtaking 5 billion messages daily. Averaged out, this means processing 58,000 messages per second, but during global peak periods—such as the morning surge in Asia when millions start their day—this rate can spike to 175,000 messages per second. This ingress pattern shapes our storage choices, demanding systems optimized for high-volume writes that can handle the ebb and flow of worldwide activity.

Once messages enter our system, they must be delivered, and this is where the load truly multiplies. In one-on-one chats, a message reaches a single recipient, but group conversations fan out to multiple participants. Assuming an average fanout factor of 3.5 recipients per message, our 5 billion daily messages expand dramatically to 17.5 billion deliveries per day. On a per-second basis, this equates to 202,000 deliveries on average, peaking at 600,000 during high-traffic windows. This fanout mechanism represents a critical stress point, where inefficient routing could turn our real-time messaging into a sluggish experience.

Layered atop messaging is the presence system, which tracks user availability to optimize delivery. With 150 million devices pinging our servers every 30 seconds to report their online status, we generate a continuous torrent of 5 million presence updates per second. Presence updates emerge as one of the most write-intensive elements of our architecture, requiring storage solutions that are not only fast but also ephemeral, as this data has a short shelf life.

To illustrate the composition of our traffic landscape, consider this pie chart that breaks down the relative volumes of different operations at peak load:

And for a flow-based view of how these elements interconnect: