Event types (domain, integration, notification) in Microservices - System Design Exercise

Design: Event Types in Microservices Architecture

Design focuses on event types and their handling in a microservices environment. Out of scope are detailed UI notification designs and specific business logic implementations.

Functional Requirements

FR1: Support domain events to capture business state changes within a service

FR2: Support integration events to communicate between different microservices asynchronously

FR3: Support notification events to inform users or external systems about important occurrences

FR4: Ensure reliable delivery of events with minimal latency

FR5: Allow event consumers to subscribe selectively to event types

FR6: Support event versioning and schema evolution

FR7: Handle failures and retries for event processing

Non-Functional Requirements

NFR1: System must handle up to 10,000 events per second

NFR2: Event delivery latency p99 should be under 200ms

NFR3: Availability target of 99.9% uptime

NFR4: Events must be durable and not lost in case of failures

NFR5: Support eventual consistency between microservices

Think Before You Design

Questions to Ask

❓ Question 1

❓ Question 2

❓ Question 3

❓ Question 4

❓ Question 5

❓ Question 6

Key Components

Event producers within microservices

Message broker or event bus (e.g., Kafka, RabbitMQ)

Event consumers or subscribers

Event schema registry for versioning

Dead letter queues for failed events

Notification service for user or external alerts

Design Patterns

Event-driven architecture

Publish-subscribe pattern

Event sourcing for domain events

CQRS (Command Query Responsibility Segregation)

Retry and dead letter queue patterns

Schema evolution and backward compatibility

Reference Architecture

 +----------------+       +----------------+       +----------------+
 |  Microservice  |       |  Message Broker |       |  Microservice  |
 |  (Event Prod)  | ----> |  (Event Bus)   | ----> |  (Event Cons)  |
 +----------------+       +----------------+       +----------------+
         |                        |                        |
         | Domain Events          | Integration Events     | Notification Events
         |                        |                        |
         v                        v                        v
 +----------------+       +----------------+       +----------------+
 | Domain Event   |       | Integration    |       | Notification   |
 | Handler       |       | Event Handler  |       | Service       |
 +----------------+       +----------------+       +----------------+

Components

Microservice Event Producer

Any microservice framework (e.g., Spring Boot, Node.js)

Generates domain events when business state changes occur

Message Broker / Event Bus

Apache Kafka or RabbitMQ

Routes integration and notification events asynchronously between services

Microservice Event Consumer

Microservice framework

Consumes integration events to update local state or trigger actions

Notification Service

Dedicated service with email/SMS/push capabilities

Sends notifications to users or external systems based on notification events

Event Schema Registry

Confluent Schema Registry or custom solution

Manages event schemas and supports versioning for compatibility

Dead Letter Queue

Message broker feature

Stores events that failed processing for later inspection or retry

Request Flow

1. 1. A microservice performs a business operation and emits a domain event internally.

2. 2. The domain event is published to the message broker as an integration event if other services need to know.

3. 3. Other microservices subscribe to integration events from the broker and update their own state accordingly.

4. 4. When a notification event is generated (either by domain or integration event handlers), it is sent to the notification service.

5. 5. The notification service delivers messages to users or external systems via email, SMS, or push notifications.

6. 6. Failed event deliveries are routed to the dead letter queue for manual or automated retries.

7. 7. Event schemas are validated and managed via the schema registry to ensure compatibility.

Database Schema

Entities: - Event: id (PK), type (domain/integration/notification), payload (JSON), timestamp, version - Subscription: id (PK), microservice_name, event_type, endpoint - Notification: id (PK), event_id (FK), recipient, status, sent_timestamp Relationships: - One Event can trigger multiple Notifications - Subscriptions link microservices to event types they consume

Scaling Discussion

Bottlenecks

Message broker throughput limits when event volume grows beyond 10K events/sec

Event consumers overwhelmed by high event processing rates

Notification service latency when sending large volumes of messages

Schema registry becoming a single point of failure

Dead letter queue growing large with many failed events

Solutions

Partition topics in message broker and scale brokers horizontally

Scale event consumers horizontally with load balancing and backpressure handling

Use bulk sending and rate limiting in notification service; integrate with third-party providers

Deploy schema registry in a highly available cluster with caching

Implement automated retries and monitoring for dead letter queue; archive old events

Interview Tips

Time: Spend 10 minutes clarifying requirements and constraints, 20 minutes designing the architecture and data flow, 10 minutes discussing scaling and trade-offs, and 5 minutes summarizing.

Explain the differences and purposes of domain, integration, and notification events clearly

Show understanding of asynchronous communication and event-driven design

Discuss how to ensure reliability and ordering in event delivery

Mention schema management and versioning importance

Address scaling challenges and practical solutions

Highlight how notifications integrate with event processing

Practice

1. Which type of event in microservices captures important business actions inside a single service?

easy

A. Domain event

B. Integration event

C. Notification event

D. System event

Solution

1. Step 1: Understand event types in microservices

   Domain events represent significant business actions occurring within a single service boundary.

2. Step 2: Differentiate from other event types

   Integration events share data between services, and notification events alert users or external systems, so they are not internal business actions.

3. Final Answer:

   Domain event -> Option A

4. Quick Check:

   Business action inside service = Domain event [OK]

Hint: Domain events are about internal business actions [OK]

Common Mistakes:

• Confusing integration events with domain events
• Thinking notification events capture business logic
• Assuming system event is a standard event type

2. Which of the following is the correct way to describe an integration event in microservices?

easy

A. An event that triggers UI updates within the same service

B. An event that shares information between different services

C. An event that sends alerts to users only

D. An event that logs errors internally

Solution

1. Step 1: Define integration events

   Integration events are designed to share information or changes between different microservices to keep them in sync.

2. Step 2: Eliminate incorrect options

   UI updates are usually local, alerts to users are notification events, and error logs are internal diagnostics, not integration events.

3. Final Answer:

   An event that shares information between different services -> Option B

4. Quick Check:

   Sharing info between services = Integration event [OK]

Hint: Integration events connect multiple services [OK]

Common Mistakes:

• Mixing notification events with integration events
• Thinking integration events only affect one service
• Confusing error logs with integration events

3. Consider this code snippet in a microservice:

publishEvent({ type: 'UserRegistered', payload: { userId: 123 } });

What type of event is this most likely representing?

medium

A. Notification event

B. System event

C. Integration event

D. Domain event

Solution

1. Step 1: Analyze the event name and context

   The event 'UserRegistered' indicates a business action inside the service, such as a user signing up.

2. Step 2: Match event type to definition

   Since it captures a business action inside the service, it is a domain event, not a notification or integration event.

3. Final Answer:

   Domain event -> Option D

4. Quick Check:

   Business action event = Domain event [OK]

Hint: Event names with business actions are domain events [OK]

Common Mistakes:

• Assuming all events are integration events
• Confusing notification events with domain events
• Ignoring event naming conventions

4. A microservice is sending an event to notify users about a password change. The event is mistakenly labeled as an integration event. What is the main issue here?

medium

A. Notification events should not be sent to users

B. Password change is a domain event, not a notification

C. Notification events should not be labeled as integration events

D. Integration events cannot carry user-related data

Solution

1. Step 1: Identify the event purpose

   The event is meant to notify users, which fits the notification event type.

2. Step 2: Understand event labeling importance

   Labeling a notification event as an integration event causes confusion and wrong handling in the system.

3. Final Answer:

   Notification events should not be labeled as integration events -> Option C

4. Quick Check:

   Correct event labeling avoids confusion [OK]

Hint: Match event label to its purpose carefully [OK]

Common Mistakes:

• Mixing notification and integration event roles
• Assuming integration events can't have user data
• Thinking notification events are internal only

5. You are designing a microservices system where a user registration triggers multiple actions: updating internal user stats, notifying other services, and sending a welcome email. Which event types should you use for these actions respectively?

hard

A. Domain event, integration event, notification event

B. Integration event, domain event, notification event

C. Notification event, domain event, integration event

D. Domain event, notification event, integration event

Solution

1. Step 1: Map actions to event types

   Updating internal user stats is a business action inside the service, so it is a domain event.

2. Step 2: Identify cross-service communication

   Notifying other services requires sharing information between services, so it is an integration event.

3. Step 3: Recognize user alerts

   Sending a welcome email is a message to the user, which fits notification events.

4. Final Answer:

   Domain event, integration event, notification event -> Option A

5. Quick Check:

   Internal action, cross-service, user alert = Domain, Integration, Notification [OK]

Hint: Match event type to action scope: internal, cross-service, user [OK]

Common Mistakes:

• Swapping integration and notification events
• Using domain events for cross-service communication
• Confusing notification with domain events