Notification System: Capacity Estimation

• Number of Tenants & Users: Suppose we serve 10-50 tenant applications. Some might be large (tens of millions of users) and others smaller. In total, imagine 100 million registered users across tenants, with 20-30 million daily active users (DAUs) generating or receiving notifications.

• Notification Volume: Assume on average each active user triggers or receives ~5 notifications per day (varies by app: social apps might be higher, e-commerce lower). That's on the order of 100-150 million notifications per day system-wide. In peak scenarios (like a viral event or big sale), this could spike higher.

  • Peak Throughput: 150 million/day is ~1.7k notifications per second on average. Peaks could be 10x higher. We should design for 20-50k notification events per second at peak. For example, if one tenant is a social network and a celebrity with 10 million followers posts something at noon, that single event could fan-out 10 million notifications, over a few minutes. That requires huge instantaneous throughput.

• Read vs Write:

  • Writes: Every notification event is a write (to databases/queues). If we have ~150M/day, that's ~1.7k writes/sec on average, with bursts as described (tens of thousands/sec).
  • Reads: Users reading notifications (in-app) also generates load. If 20M users check their in-app notifications roughly once a day, that could be 20M read operations per day (~230 reads/sec average, but likely spiky around morning/evening). Many reads will fetch a small list (the user's recent notifications).
  • In real-time, many users will get notifications pushed without needing to pull, but when they open the app or if they load an inbox, it triggers reads. Write volume (sending notifications) will likely exceed read volume if push delivery is common.

• Storage:

  • Notification Storage: If we store notifications for in-app history, assume we keep the last 100 notifications per user. With 100M users, that's up to 10 billion notification records in storage. However, not all users are active; focusing on 20M actives with, say, 50 each, it's around 1 billion records. If each stored notification entry is ~500 bytes (including message text, metadata), 1 billion records is ~500 GB. Add overhead and replication, a few TB of storage needed. This is large but manageable with distributed databases.
  • Preferences Storage: One record per user for preferences (which channels enabled, quiet hours etc.). 100M users * a few hundred bytes each = tens of GB. This can fit in a SQL DB partitioned or a NoSQL easily.
  • Other Data: Possibly device tokens for push, email addresses if stored here (though user data might live in tenant's DB - we might just receive those when sending).
  • Bandwidth: Pushing text-based notifications is relatively lightweight. For example, 100M notifications * ~1KB each on average = ~100 GB of data transferred per day just in notification payloads. We need network capacity for this, but it's feasible across a distributed system.

• Latency Expectation:

  • In-app/push: ideally <1-2 seconds from event to device notification. So our pipeline (ingestion -> processing -> push) should introduce minimal delay (tens or low hundreds of milliseconds at each step).
  • Email/SMS: Sending of an email within ~1 minute is fine. External email gateways might introduce some seconds of delay, but generally sending out an email should be a sub-second operation on our side; the email might arrive in inbox seconds or tens of seconds later.
  • We'll have to buffer or queue events, but the queue should not add too much delay except during enormous spikes.

• Throughput per Channel:

  • Push notifications: If a major event happens, we might send tens of thousands per second to APNs/FCM. We need to maintain connections and possibly throttle per provider guidelines.
  • Emails: If using an email service or server, sending thousands per second is possible but might need multiple servers or providers for large scale. (150M/day emails would be extremely high; realistically, not all notifications go via email - many are in-app or push. Email might be a smaller fraction of total notifications.)
  • SMS: Likely lower volume due to cost and use-case (used only for urgent things like 2FA or order updates). Could be tens of thousands a day at most, which is trivial in comparison - but SMS has costs and external gateway limits that we'd account for.

These estimations highlight the need for aggressive horizontal scaling (lots of parallel processing), efficient data partitioning, and asynchronous processing. The system must be distributed to handle peak loads and large storage.

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