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.