0
0
Microservicessystem_design~10 mins

Event types (domain, integration, notification) in Microservices - Scalability & System Analysis

Choose your learning style9 modes available
Scalability Analysis - Event types (domain, integration, notification)
Growth Table: Event Types in Microservices
Users / EventsDomain EventsIntegration EventsNotification Events
100 usersFew 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 usersHundreds 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 usersThousands 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 usersMillions 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.
First Bottleneck

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.

Scaling Solutions
  • 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.
Back-of-Envelope Cost Analysis
  • 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.
Interview Tip

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.

Self Check

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.

Key Result
Integration event brokers become the first bottleneck as event volume grows; horizontal scaling with partitioning is the primary solution.