| Users / Events | Domain Events | Integration Events | Notification Events |
|---|---|---|---|
| 100 users | Few domain events per second, simple event handling within services. | Low integration events, direct service calls mostly. | Notifications sent manually or via simple queues. |
| 10,000 users | Hundreds of domain events/sec, event sourcing or CQRS may start. | Integration events increase, async messaging used for decoupling. | Notifications automated, batched, and queued. |
| 1,000,000 users | Thousands of domain events/sec, event stores and replay needed. | High volume integration events, message brokers scale horizontally. | Notifications use push services, throttling, and personalization. |
| 100,000,000 users | Millions of domain events/sec, partitioned event streams, multi-region replication. | Integration events require global event mesh, guaranteed delivery. | Notifications use CDN, multi-channel, and real-time delivery at scale. |
Event types (domain, integration, notification) in Microservices - Scalability & System Analysis
The first bottleneck is usually the event broker or message queue system handling integration events.
At small scale, domain events are handled within services easily.
As user count grows, the broker's throughput and latency limits appear first because it must reliably deliver many events to multiple consumers.
- Horizontal scaling: Add more broker nodes (e.g., Kafka partitions) to distribute event load.
- Partitioning: Split event streams by domain or customer to isolate traffic.
- Caching: Use caches for notification content to reduce recomputation.
- Event filtering: Consumers subscribe only to relevant events to reduce processing.
- Backpressure and throttling: Control event flow to avoid overload.
- Multi-region replication: For global scale, replicate event brokers closer to users.
- At 1M users, assume 10 domain events/user/day -> ~115 events/sec.
- Integration events multiply by number of services; assume 10x domain events -> ~1,150 events/sec.
- Notification events depend on user activity; assume 5 notifications/user/day -> ~58 notifications/sec peak.
- Storage: Event logs grow by millions daily; need scalable storage like distributed logs.
- Bandwidth: Event payloads small (~1KB), so 1,150 events/sec ≈ 1.15 MB/s; notifications may require more bandwidth if multimedia.
Start by defining each event type clearly: domain, integration, notification.
Explain how their scale differs and why their bottlenecks differ.
Discuss the event flow and how you would scale each component step-by-step.
Use real numbers to show understanding of throughput and storage.
Your event broker handles 1000 QPS integration events. Traffic grows 10x. What do you do first?
Answer: Add partitions and broker nodes to horizontally scale the event broker, distributing load and maintaining throughput.