Notification System: Capacity Estimation

Tenants and users. Suppose we serve 10 to 50 tenant applications. Some are large, with tens of millions of users, and others are small. In total, imagine 100 million registered users across all tenants. Of those, 20 to 30 million are daily active users (DAUs) who send or receive notifications.

Notification volume. Assume each active user triggers or receives about 5 notifications a day. Social apps run higher and e-commerce lower, but 5 is a fair average. That gives around 100 to 150 million notifications a day across the whole system. A viral event or a big sale pushes it higher for a while.

Peak throughput. 150 million a day is about 1.7k notifications per second on average. Peaks could be more than 10x that. So we design for 20 to 50k notification events per second at peak. It is worth seeing where a peak like that comes from. Say one tenant is a social network. A celebrity with 10 million followers posts at noon. That single event turns into 10 million notifications within a few minutes. One event becoming many notifications like this is called fan-out. The system needs very high throughput for that short window.

Writes. Every notification event is a write, to a queue and to a database. At 150 million a day, that is about 1.7k writes per second on average. The bursts described above reach tens of thousands per second.

Reads. Users reading their in-app notifications add load too. If 20 million users open their list about once a day, that is 20 million reads a day. That averages about 230 reads per second, though it will spike in the morning and evening. Most reads fetch a small list, the user's recent notifications.

Writes will outnumber reads. Most systems read far more than they write, and this one does not. Most notifications are pushed to the user, so nobody has to pull them. A read happens only when someone opens the app or loads the inbox. If push delivery is common, write volume will be higher than read volume.

Notification storage. For in-app history, assume we keep the last 100 notifications per user. With 100 million users, that is up to 10 billion records. But not every user is active. Counting only 20 million active users at, say, 50 each gives about 1 billion records. At about 500 bytes per record, including text and metadata, 1 billion records is about 500 GB. With overhead and replication, we need a few TB. That is large but fine for a distributed database.

Preferences and other data. One record per user holds their preferences: which channels are on, quiet hours, and so on. 100 million users at a few hundred bytes each is tens of GB. That fits easily in a partitioned SQL database or a NoSQL store. We may also hold device tokens for push and email addresses. This user data may live in the tenant's own database instead. In that case, we simply receive it with each send.

Bandwidth. Text notifications are small. 100 million notifications at about 1 KB each is about 100 GB of payload a day. We need network capacity for that, but a distributed system handles it without trouble.

Latency. For in-app and push, aim for under 1 to 2 seconds from event to device. So each stage of the pipeline, from intake to processing to push, should add only tens or low hundreds of milliseconds. Email and SMS are looser. Sending an email within about a minute is fine. Handing the message to the email gateway should take under a second on our side. The email itself may reach the inbox seconds or tens of seconds later. We will also buffer events in a queue, and that queue should add little delay except during a very large spike.

What each channel can take. Those peaks do not arrive on one channel, and each channel has its own limit. During a major event, we might send tens of thousands of pushes per second to APNs and FCM. So we keep connections open to those services and stay within their rate guidelines. An email service or server can send thousands per second, and large scale may need several servers or providers. 150 million emails a day would be very high. In practice, most notifications go by in-app or push, and email is a smaller share. SMS volume is lower again, because each message costs money. It is used for urgent things like two-factor codes and order updates. It might be tens of thousands a day at most, which is tiny by comparison. But SMS has per-message costs and gateway limits that we must plan for.

These estimates point to three needs: many machines working in parallel, careful data partitioning, and asynchronous processing. The system must be distributed to handle the peak load and the storage.

Two numbers matter for the rest of the design. The first is about 150 million notifications a day. The second is a fan-out event that turns one publish into tens of thousands a second. Every later step is sized against those two.