Tech VocabularyYour engineering team says "we need an event busWhat is event bus?A messaging infrastructure component through which services publish events and other services subscribe to them, enabling decoupled communication." or "let's add CQRSWhat is cqrs?Command Query Responsibility Segregation - using separate models for read and write operations so each can be optimized independently.." These terms solve concrete problems: handling traffic spikes, keeping services running when parts fail, and processing millions of actions without dropping any.
Event-driven architecture: reacting to change
Instead of services calling each other directly ("Hey, do this now!"), they publish events to a central message broker:
1. Order Service: "OrderPlaced event published"
2. Payment Service: "I heard OrderPlaced, processing payment..."
3. Inventory Service: "I heard OrderPlaced, reserving stock..."
4. Notification Service: "I heard OrderPlaced, sending confirmation email..."The order service doesn't know or care who listens. It just announces the event and moves on.
Why teams love events
- Loose coupling: Add a new service that listens to OrderPlaced? No changes to existing code
- Resilience: If the email service is down, the order still processes. Emails send when the service recovers
- Scalability: Multiple instances of a service can listen to the same events, sharing the workload
- Audit trail: Every event is logged, replay what happened for any order
CQRSWhat is cqrs?Command Query Responsibility Segregation - using separate models for read and write operations so each can be optimized independently.: separating reads from writes
CQRS (Command Query Responsibility Segregation) uses different models for reading and writing data.
Consider a reservation system: taking reservations (writes) is complex, prevent double-booking, check availability, collect info. Looking up reservations (reads) is simple but happens 100x more often. CQRS says: optimize separately.
When CQRS makes sense
- Read-heavy applications: Users view content 1000 times for every 1 edit
- Complex domains: Writing rules are complicated; reading is simple
- Different scaling needs: Writes need strong consistency; reads can be eventually consistent
CQRS adds complexity, two data stores to keep in sync. It's overkill for simple applications but powerful for complex ones.
Message queues and event buses
These are the plumbing that makes event-driven architecture work.
A message queue is a to-do list for services. Service A adds a message; Service B picks it up when ready.
Service A: "Send welcome email to alice@example.com" → Queue
Service B (Email Service): Picks up message, sends email, deletes from queueBenefits: buffering (queue holds 10,000 emails while the service catches up), reliability (messages persist through restarts), and load leveling (smooth out spikes). Popular systems: RabbitMQ, AWS SQS, Apache Kafka.
An event busWhat is event bus?A messaging infrastructure component through which services publish events and other services subscribe to them, enabling decoupled communication. is like a radio broadcast, one service publishes, any number of services listen:
Order Service publishes: "OrderPlaced"
↓
Payment Service hears it → processes payment
Inventory Service hears it → reserves stock
Analytics Service hears it → logs metricsKey difference: Queues deliver to one consumer (send this email once). Event buses broadcast to many consumers (order placed triggers many reactions).
Load balancing: sharing the work
Load balancing distributes incoming traffic across multiple servers so no single server is overwhelmed.
Users → Load Balancer → Server 1
→ Server 2
→ Server 3The load balancerWhat is load balancer?A server that distributes incoming traffic across multiple backend servers so no single server gets overwhelmed. (Nginx, HAProxy, AWS ELB) routes each request to a healthy server and continuously monitors server health, if one crashes, traffic reroutes automatically.
| Strategy | How it works | Best for |
|---|---|---|
| Round Robin | Each server takes turns | Servers with equal capacity |
| Least Connections | Send to server with fewest active requests | Variable request durations |
| IP Hash | Same user always goes to same server | Session persistence |
| Weighted | Some servers get more traffic | Mixed server sizes |
High availability: staying online
High availability (HA) means your application keeps working even when things break. It's measured as uptime percentage: 99.9% allows 8.76 hours of downtime per year; 99.99% allows just 52 minutes.
HA relies on redundancy: backup systems ready to take over:
Single point of failure: High availability:
User → Server User → Load Balancer → Server 1
↘ Server 2 (standby)
↘ Server 3 (standby)HA strategies
- Multi-zone deployment: Run in multiple data centers; if one goes down, traffic shifts
- Database replication: Copies of data in multiple locations; replicas take over on failure
- Auto-scaling: Add servers when traffic increases, remove when it decreases
- Circuit breakers: Stop calling a failing service to prevent cascading failures
Putting it together
A modern e-commerce platform might combine all these concepts:
User → CDN/Load Balancer → Frontend servers (auto-scaling)
→ API Gateway
├─ Catalog Service (CQRS: separate read/write models)
├─ Order Service (publishes events: OrderPlaced, OrderCancelled)
├─ Payment Service (listens for OrderPlaced)
└─ Notification Service (serverless, triggered by events)
Message Queue: image processing, report generation
Event Bus: coordinates actions across servicesThese concepts solve real problems as your product grows. Event-driven architecture decouples teams. CQRSWhat is cqrs?Command Query Responsibility Segregation - using separate models for read and write operations so each can be optimized independently. optimizes for different access patterns. Message queues provide reliability. Load balancing and HA keep you online. Understanding these tradeoffs lets you participate meaningfully in architecture discussions.