Skip to main content

Event-Driven Architecture Flow 📡

This document explains how ShopVerse uses an event-driven architecture (EDA) with Apache Kafka to achieve loose coupling, scalability, and resilience across microservices.

Event-driven communication is used for non-critical, asynchronous workflows such as notifications, analytics, and recommendations.

🎯 Why Event-Driven Architecture?​

In a microservices system, direct synchronous calls can cause:

  • Tight coupling
  • Cascading failures
  • Poor scalability

ShopVerse uses Kafka-based events to ensure:

  • Services remain independent
  • Failures do not propagate
  • New consumers can be added without changing producers

🧠 Core Idea​

Services publish events about what happened.
Other services react to those events independently.

No service directly calls another service for side effects like notifications or analytics.

🗺️ High-Level Event Flow​


Core Services  →  Kafka Topics  →  Consumer Services

Core services produce events.
Consumer services subscribe and react.

🏗️ Event-Driven Architecture Diagram (Mermaid)​

📦 Events in ShopVerse​

Each event represents a business fact.

Common Event Types:​

  • USER_REGISTERED
  • USER_LOGIN
  • PRODUCT_CREATED
  • PRODUCT_UPDATED
  • ORDER_PLACED
  • PAYMENT_SUCCESS

Events are immutable and append-only.

📡 Kafka Topics Design​

Topic NamePurpose
auth-eventsUser login & registration
product-eventsProduct lifecycle changes
order-eventsOrder placement & updates
payment-eventsPayment status changes
analytics-eventsAggregated analytics data

🧩 Event Payload Structure​

All services follow a standardized event schema:

{
  "eventType": "ORDER_PLACED",
  "service": "ORDER_SERVICE",
  "userEmail": "user@example.com",
  "entityId": "ORD123",
  "amount": 2499.00,
  "timestamp": "2026-01-21T10:30:00",
  "metadata": {
    "paymentMode": "UPI"
  }
}

Why Standardization?​

  • Easy to consume
  • Easier debugging
  • Future-proof
  • Analytics-friendly

🔁 Event Publishing Flow​

Example: Order Placement​

🔄 Consumer Groups & Scaling​

  • Each consumer service runs in its own consumer group
  • Kafka distributes partitions across instances
  • Consumers can scale horizontally

Example:​

notification-service-group
analytics-service-group
recommendation-service-group

🛡️ Idempotency & Reliability​

Challenges:​

  • Duplicate events
  • Consumer restarts
  • Network failures

Solutions:​

  • Unique event identifiers
  • Idempotent consumer logic
  • Offset commits after successful processing
  • Retry & dead-letter strategies (future-ready)

⚠️ Failure Scenarios​

❌ Consumer Down​

  • Kafka retains events
  • Consumer resumes from last offset

❌ Producer Failure​

  • Transaction rollback prevents event publishing
  • Partial state avoided

❌ Duplicate Events​

  • Handled using idempotent checks

📈 Benefits Achieved​

ConcernHow EDA Solves It
Loose couplingNo direct service calls
ScalabilityIndependent scaling
ResilienceFailure isolation
ExtensibilityAdd consumers easily
PerformanceNon-blocking flows

🧠 Why Not Everything Is Event-Driven?​

ShopVerse uses hybrid communication:

  • REST → Critical, immediate responses
  • Kafka → Side effects & async workflows

This balances consistency and performance.

📌 Summary​

ShopVerse’s event-driven architecture:

  • Decouples services
  • Improves resilience
  • Enables future growth
  • Reflects real-world backend design

Kafka acts as the central nervous system of the platform.