Module 3 - Asynchronous Processing

Event-Driven Architecture

Build loosely coupled systems where services communicate through events instead of direct calls.

1The News Broadcast Analogy

Simple Analogy
Instead of a reporter calling every citizen individually with news (synchronous), a news station broadcasts the event, and anyone interested tunes in.

The reporter doesn't know (or care) who's listening. Citizens subscribe to channels they care about. This is publish-subscribe-the heart of event-driven systems.

Event-Driven Architecture (EDA) is a design pattern where services communicate by producing and consuming events. Services are decoupled-they don't call each other directly.

2Request-Response vs Event-Driven

Request-Response (Synchronous)

Order Service
↓ call ↓
Inventory Service
↓ call ↓
Payment Service
↓ call ↓
Notification Service
  • • Order waits for all calls to complete
  • • Tightly coupled
  • • One failure = whole chain fails

Event-Driven (Asynchronous)

Order Service
↓ publish "OrderCreated" ↓
Event Bus
Inventory
Payment
Notification
  • • Order publishes and continues
  • • Loosely coupled
  • • Services fail independently

3Core Concepts

EventAn immutable fact that something happened. Example: 'OrderCreated', 'UserSignedUp', 'PaymentFailed'
ProducerService that publishes events when something happens. Doesn't know who's listening.
ConsumerService that subscribes to events and reacts to them.
Event Bus/BrokerInfrastructure that routes events from producers to consumers. (Kafka, RabbitMQ, SNS)
Topic/ChannelNamed category of events. Consumers subscribe to specific topics.

4Event Types

Domain Events

Business facts that happened

OrderPlacedUserRegisteredPaymentReceived
Integration Events

Cross-service communication

NewOrderForShippingCustomerUpdated
System Events

Infrastructure & monitoring

ServiceStartedErrorOccurredMetricRecorded

5Event Schema Design

Well-Designed Event
{
  "eventId": "evt_abc123",           // Unique ID for idempotency
  "eventType": "OrderCreated",       // What happened
  "timestamp": "2024-01-15T10:30:00Z", // When it happened
  "version": "1.0",                  // Schema version
  "source": "order-service",         // Who published it
  "correlationId": "req_xyz789",     // Trace across services
  "data": {                          // Event-specific payload
    "orderId": "ord_456",
    "customerId": "cust_789",
    "items": [...],
    "total": 99.99
  }
}
Schema Best Practices

Include enough data for consumers to act without calling back. But don't include everything- keep events focused on the fact that happened.

6Patterns

Event Notification

Event signals something happened, consumer fetches details if needed.

{ type: 'OrderCreated', orderId: '123' }

Lightweight. Consumer calls Order Service for full details.

Event-Carried State Transfer

Event carries all the data consumers need.

{ type: 'OrderCreated', order: { id, items, total, customer } }

No callback needed. But larger payloads, possible stale data.

Event Sourcing

Store all events as source of truth. Derive current state by replaying.

AccountOpened→MoneyDeposited($100)→MoneyWithdrawn($30)=Balance: $70

Full audit trail. Can rebuild state at any point in time.

7Benefits & Challenges

✓ Benefits
  • • Loose coupling-services evolve independently
  • • Better scalability-add consumers without changing producer
  • • Resilience-failures don't cascade
  • • Auditability-event log shows what happened
  • • Replay-reprocess events if needed
✗ Challenges
  • • Complexity-harder to trace flow
  • • Eventual consistency-not immediately consistent
  • • Debugging-distributed tracing needed
  • • Ordering-may receive events out of order
  • • Schema evolution-versioning challenges

8Key Takeaways

1EDA decouples services-they communicate through events, not direct calls.
2Events are facts-immutable records of something that happened.
3Publish-Subscribe: producer doesn't know consumers; consumers subscribe to topics.
4Include eventId for idempotency, correlationId for tracing.
5Choose between notification (light) vs state transfer (complete data).
6Accept eventual consistency-design your UX around it.