Event-driven architecture (EDA) is a software design pattern where system components communicate through asynchronous events rather than direct synchronous calls, enabling microservices to scale independently, respond to changes in real-time, and maintain loose coupling — making it the foundation of modern distributed systems used by companies from Razorpay and PhonePe to Flipkart and Swiggy. For Indian tech teams building scalable applications, EDA with tools like Apache Kafka, RabbitMQ, or AWS EventBridge transforms brittle monoliths into resilient, responsive systems that handle millions of transactions.
Last updated October 2026
What Is Event-Driven Architecture and Why Does It Matter?
In traditional request-response architecture, Service A calls Service B directly and waits for a response. If Service B is slow or down, Service A is blocked. In event-driven architecture:
- Service A publishes an event (“Order Placed”) to a message broker
- The broker distributes the event to all interested services
- Service B (Inventory), Service C (Payment), and Service D (Notification) each process the event independently
- No service waits for another — they’re decoupled
Core benefits:
- Scalability: Each service scales independently based on its own load. The payment service can scale up during sales without affecting inventory.
- Resilience: If the notification service goes down, orders still process. Events queue up and are processed when the service recovers.
- Real-time responsiveness: Events propagate instantly — user sees order confirmation while inventory, billing, and shipping process in parallel.
- Loose coupling: Services don’t know about each other. Adding a new service (analytics, fraud detection) requires zero changes to existing services.
- Auditability: Events form a natural audit log of everything that happened in the system.
What Are the Key Patterns in Event-Driven Architecture?
1. Event Notification
The simplest pattern. A service publishes a lightweight event (“OrderPlaced, orderId: 12345”), and consumers react. The event doesn’t carry full data — consumers may need to query the source service for details.
2. Event-Carried State Transfer
Events carry the full data needed for processing (“OrderPlaced, orderId: 12345, items: […], total: ₹5,999”). Consumers don’t need to call back to the source, reducing coupling and network calls at the cost of larger event payloads.
3. Event Sourcing
Instead of storing just the current state, you store every event that led to the current state. The state is rebuilt by replaying events:
- AccountCreated → BalanceCredited(₹10,000) → BalanceDebited(₹3,000) → BalanceCredited(₹5,000)
- Current balance: ₹12,000 (derived by replaying all events)
Used in financial systems, inventory management, and anywhere a complete audit trail is critical. Indian fintech companies like Razorpay use event sourcing for transaction processing.
4. CQRS (Command Query Responsibility Segregation)
Separate the write model (commands: create, update, delete) from the read model (queries: list, search, report). Commands produce events; events update read-optimised views (materialised views).
CQRS with event sourcing is powerful for systems where read and write patterns differ significantly — e.g., an e-commerce system where product updates are infrequent but product searches happen millions of times daily.
5. Saga Pattern
Manages distributed transactions across microservices using a sequence of events and compensating actions. Example: an order process spanning payment, inventory, and shipping services. If payment succeeds but inventory is unavailable, a compensating event reverses the payment.
Which Message Broker Should You Choose?
Apache Kafka
- Best for: High-throughput, persistent event streams, log aggregation, real-time data pipelines
- Throughput: Millions of messages/second
- Persistence: Events stored on disk with configurable retention (days/weeks/forever)
- Consumer groups: Multiple consumers process events independently
- Learning curve: High — requires ZooKeeper/KRaft cluster management, partitioning strategy, consumer offset management
- Cost (managed): Confluent Cloud starts at ~$0.10/GB; AWS MSK from $0.21/hour; self-hosted requires dedicated infrastructure
- Used by: Flipkart, Swiggy, Razorpay, PhonePe, LinkedIn, Netflix
RabbitMQ
- Best for: Task queues, request-response patterns, complex routing, smaller-scale applications
- Throughput: Tens of thousands of messages/second (lower than Kafka)
- Features: Flexible routing (direct, topic, fanout, headers exchanges), message acknowledgment, dead-letter queues
- Learning curve: Medium — easier to start than Kafka, well-documented
- Cost: Open source (self-hosted), CloudAMQP managed service from $19/month
AWS EventBridge / SNS+SQS
- Best for: AWS-native applications, serverless architectures, simple event routing
- Integration: Native with Lambda, Step Functions, and 100+ AWS services
- Cost: Pay-per-event ($1 per million events on EventBridge), zero infrastructure management
- Best for Indian startups: On AWS, using EventBridge + SQS is the fastest path to EDA without managing brokers
How to Implement Event-Driven Architecture: A Practical Guide
- Identify domain events: Map your business processes. What events matter? OrderPlaced, PaymentReceived, InventoryUpdated, UserRegistered, InvoiceGenerated.
- Define event schemas: Use a schema registry (Confluent Schema Registry for Kafka, or JSON Schema/Avro). Include event type, version, timestamp, correlation ID, and payload.
- Choose your broker: Kafka for high-throughput streaming, RabbitMQ for task queues, cloud-native (EventBridge/Pub/Sub) for serverless.
- Implement producers: Services that emit events. Ensure idempotent event production (no duplicate events on retry).
- Implement consumers: Services that react to events. Ensure idempotent processing (processing the same event twice should not corrupt state).
- Handle failures: Dead-letter queues for unprocessable events, retry with exponential backoff, alerting on failed events.
- Observability: Distributed tracing (Jaeger, Zipkin), event flow visualisation, consumer lag monitoring, alerting.
What Are Common Pitfalls of Event-Driven Architecture?
- Eventual consistency confusion: EDA systems are eventually consistent, not immediately consistent. Users may see stale data briefly. Design UIs to handle this gracefully.
- Event schema evolution: Changing event formats without backward compatibility breaks consumers. Use schema versioning from day one.
- Debugging complexity: Tracing a request across 10 event-driven services is harder than tracing a synchronous call chain. Invest in correlation IDs and distributed tracing.
- Over-engineering: Not every system needs EDA. A small CRUD application with 100 users should not use Kafka. Start with synchronous, add events where they solve real problems.
- Event ordering: Kafka guarantees ordering within a partition, not across partitions. Design your partitioning strategy carefully for events that require order (e.g., all events for one order go to the same partition).
Frequently Asked Questions
When should I use event-driven architecture vs REST APIs?
Use REST for synchronous, request-response interactions where the client needs an immediate answer (e.g., “Get user profile”). Use events for asynchronous processes where the producer doesn’t need to wait (e.g., “Order placed — trigger inventory, payment, notification independently”). Most real systems use both — REST for reads and commands, events for reactions and workflows.
Is event-driven architecture suitable for small Indian startups?
Start simple. Use cloud-managed services (AWS SQS + SNS, Google Pub/Sub) rather than self-hosting Kafka. Even a 3-person team can benefit from decoupling order processing from email notifications using a simple queue. Grow your EDA sophistication as your system and team grow.
How do I ensure data consistency in an event-driven system?
Use the Transactional Outbox pattern: write the event to an “outbox” table in the same database transaction as the state change. A separate process reads the outbox and publishes to the message broker. This ensures the event is published if and only if the state change committed. Debezium (change data capture) automates this with Kafka.
What is the cost of running Kafka for an Indian startup?
Self-hosted Kafka on AWS (3-node cluster, t3.medium instances) costs approximately ₹15,000–₹25,000/month. Confluent Cloud starts at a few dollars/month for light usage. For startups processing under 10,000 events/day, AWS SQS (₹0.33 per million requests) is far more cost-effective than Kafka.
Can event-driven architecture work with monolithic applications?
Yes. The “Strangler Fig” pattern lets you extract one service at a time from a monolith, communicating via events. Start by publishing events from the monolith for new services to consume. Gradually, the monolith shrinks as more functionality moves to event-driven microservices.
The MAD designs and builds scalable, event-driven software systems for businesses across India. Whether you’re migrating from a monolith or building a new microservices platform, our development team architects systems that grow with your business. Discuss your architecture needs.
