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

Problem Statement

When microservices communicate, mixing different kinds of events without clear separation causes confusion, tight coupling, and harder maintenance. Without distinguishing event types, teams struggle to know which events trigger internal logic, which coordinate between services, and which inform users or external systems.

Solution

Classify events into domain, integration, and notification types to clarify their purpose and scope. Domain events represent important business state changes within a service. Integration events coordinate actions across services by sharing state changes. Notification events inform users or external systems about events without affecting business logic. This separation improves decoupling and clarity.

Architecture

┌─────────────┐       ┌───────────────┐       ┌───────────────┐
│ Domain      │       │ Integration   │       │ Notification  │
│ Events      │──────▶│ Events        │──────▶│ Events        │
│ (Internal)  │       │ (Cross-service│       │ (User/External│
└─────────────┘       │ communication)│       │ communication)│
                      └───────────────┘       └───────────────┘

This diagram shows the flow and separation of event types: domain events occur inside a service, integration events share state changes between services, and notification events inform users or external systems.

Trade-offs

✓ Pros

→

Improves clarity by defining event responsibilities clearly.

→

Reduces tight coupling between microservices by separating internal and cross-service events.

→

Facilitates easier maintenance and evolution of services.

→

Enables targeted handling and scaling strategies per event type.

✗ Cons

→

Adds complexity in event design and requires discipline to maintain separation.

→

May increase the number of events and infrastructure overhead.

→

Requires clear documentation and team alignment to avoid misuse.

Use when building microservices with asynchronous communication and multiple teams managing different services, especially when business logic and integration concerns must be separated at scale (100+ services or high event volume).

Avoid when building simple or monolithic applications with minimal asynchronous communication or when event volume is very low (<100 events per minute), as the overhead outweighs benefits.

Real World Examples

Uber

Uber uses domain events to track ride status changes internally, integration events to synchronize data between services like payments and notifications, and notification events to inform users about ride updates.

Netflix

Netflix separates domain events for user activity within services, integration events to coordinate between microservices like recommendations and billing, and notification events to send alerts or emails to users.

Amazon

Amazon uses domain events to represent order state changes, integration events to update inventory and shipping services, and notification events to send order confirmations and delivery updates to customers.

Code Example

The before code mixes all event types in one method using string checks, causing confusion and tight coupling. The after code defines separate classes for each event type and processes them with dedicated handlers, improving clarity and separation of concerns.

Microservices

### Before: Mixed event handling without clear types
class EventProcessor:
    def process(self, event):
        if event['type'] == 'order_created':
            self.handle_order_created(event)
        elif event['type'] == 'payment_received':
            self.handle_payment(event)
        elif event['type'] == 'send_email':
            self.handle_notification(event)

### After: Clear event type separation
class DomainEvent:
    def __init__(self, data):
        self.data = data

class IntegrationEvent:
    def __init__(self, data):
        self.data = data

class NotificationEvent:
    def __init__(self, data):
        self.data = data

class EventProcessor:
    def process(self, event):
        if isinstance(event, DomainEvent):
            self.handle_domain_event(event)
        elif isinstance(event, IntegrationEvent):
            self.handle_integration_event(event)
        elif isinstance(event, NotificationEvent):
            self.handle_notification_event(event)

    def handle_domain_event(self, event):
        # business logic
        pass

    def handle_integration_event(self, event):
        # cross-service coordination
        pass

    def handle_notification_event(self, event):
        # user or external notifications
        pass

Alternatives

Event Sourcing

Stores all changes as a sequence of events representing state changes, focusing on persistence rather than event type separation.

Use when: Choose when you need full audit trails and the ability to reconstruct state from events.

Command Query Responsibility Segregation (CQRS)

Separates read and write models, often using events to update read models, but focuses on query optimization rather than event type classification.

Use when: Choose when read and write workloads differ significantly and need separate optimization.

Summary

Separating events into domain, integration, and notification types clarifies their roles and reduces coupling in microservices.

Domain events represent internal business changes, integration events coordinate between services, and notification events inform users or external systems.

This separation improves maintainability, scalability, and team collaboration in complex distributed systems.