Principles of Message Queues and Event-Driven ArchitecturePrinciples of Message Queues and Event-Driven Architecture

------

1. Motivation for the "Message Queues"1. Motivation for the "Message Queues"

1.1 A Real-World Case: The Evolution of Taobao's Order System1.1 A Real-World Case: The Evolution of Taobao's Order System

In 2012, Taobao's order system suffered a severe outage. At midnight on Double 11, traffic flooded in instantly. The order service directly called the inventory service, payment service, logistics service... the entire chain collapsed like dominoes.In 2012, Taobao's order system suffered a severe outage. At midnight on Double 11, traffic flooded in instantly. The order service directly called the inventory service, payment service, logistics service... the entire chain collapsed like dominoes.

The architecture at the time (tight coupling):The architecture at the time (tight coupling):

User places order → Order service → Sync call inventory service → Sync call payment service → Sync call logistics service ↓ ↓ ↓ Response 200ms Response 500ms Response 300ms

Improved architecture (introducing message queues):Improved architecture (introducing message queues):

User places order → Order service → Send "order created" message → Immediate return (50ms) ↓ Message queue (Kafka) ↓ ┌─────────────┬─────────────┬─────────────┐ ▼ ▼ ▼ ▼ Inventory Payment Logistics Notification service service service service (async deduct) (async process) (async create) (async send)

1.2 Everyday Analogies for Message Queues1.2 Everyday Analogies for Message Queues

Restaurant Queuing SystemRestaurant Queuing System

Imagine going to a popular restaurant:Imagine going to a popular restaurant:

• No queuing system: Customers must stand at the window waiting; limited window space, long lines behind, restaurant under pressureNo queuing system: Customers must stand at the window waiting; limited window space, long lines behind, restaurant under pressure
• With queuing system: After ordering, you get a number; you can sit down first, pick up food when your number is calledWith queuing system: After ordering, you get a number; you can sit down first, pick up food when your number is called

A message queue is the software system's "queuing system":A message queue is the software system's "queuing system":

• Producer (the person ordering) → Puts messages (orders) into the queueProducer (the person ordering) → Puts messages (orders) into the queue
• Queue (the number dispenser) → Temporarily stores messagesQueue (the number dispenser) → Temporarily stores messages
• Consumer (the chef) → Processes messages at their own paceConsumer (the chef) → Processes messages at their own pace

------

2. Overview of a Message Queue (Definition + Core Three Elements)2. Overview of a Message Queue (Definition + Core Three Elements)

2.1 Overview of a "Message Queue"2.1 Overview of a "Message Queue"

2.2 The Three Core Elements of a Message Queue2.2 The Three Core Elements of a Message Queue

Element 1: ProducerElement 1: Producer

Responsibility: Create and send messages to the queue.Responsibility: Create and send messages to the queue.

Analogy: The producer is like a "sender," delivering letters (messages) to the post office (queue).Analogy: The producer is like a "sender," delivering letters (messages) to the post office (queue).

Element 2: ConsumerElement 2: Consumer

Responsibility: Get messages from the queue and process them.Responsibility: Get messages from the queue and process them.

Analogy: The consumer is like a "recipient," taking letters (messages) from the mailbox (queue) and processing them.Analogy: The consumer is like a "recipient," taking letters (messages) from the mailbox (queue) and processing them.

Element 3: Broker (Message Broker)Element 3: Broker (Message Broker)

Responsibility: Receive, store, and forward messages.Responsibility: Receive, store, and forward messages.

Analogy: The Broker is like a "post office" or "package sorting station," responsible for receiving, sorting, and delivering letters.Analogy: The Broker is like a "post office" or "package sorting station," responsible for receiving, sorting, and delivering letters.

------

3. Core Problem 1: Approach to Decoupling Systems and Avoid "Pulling One Thread and Moving the Whole System"3. Core Problem 1: Approach to Decoupling Systems and Avoid "Pulling One Thread and Moving the Whole System"

3.1 The Tragedy of Tight Coupling: One Service Goes Down, Everything Falls3.1 The Tragedy of Tight Coupling: One Service Goes Down, Everything Falls

Scenario recreation: An e-commerce platform's early architectureScenario recreation: An e-commerce platform's early architecture

Order service directly calls downstream services: ┌─────────────┐ │ Order │ │ Service │ └──────┬──────┘ │ ├───────────┬───────────┬───────────┐ ▼ ▼ ▼ ▼ ┌──────────┐ ┌──────────┐ ┌──────────┐ ┌──────────┐ │Inventory │ │Payment │ │Logistics │ │SMS │ │Service │ │Service │ │Service │ │Service │ │ 200ms │ │ 500ms │ │ 300ms │ │ 100ms │ └──────────┘ └──────────┘ └──────────┘ └──────────┘

3.2 Decoupling Solution: Introduce Message Queue as "Middle Layer"3.2 Decoupling Solution: Introduce Message Queue as "Middle Layer"

Architecture after decoupling:Architecture after decoupling:

Order service only sends messages, doesn't care who consumes: ┌─────────────┐ │ Order │ ──Send "order created" message──┐ │ Service │ │ └─────────────┘ ▼ ┌───────────────────┐ │ Message Queue │ │ (Kafka/RabbitMQ) │ │ - Reliable store │ │ - Multi-replica │ │ - Order guarantee│ └─────────┬─────────┘ │ ┌───────────────────────┼───────────────────────┐ │ │ │ ▼ ▼ ▼ ┌──────────────┐ ┌──────────────┐ ┌──────────────┐ │ Inventory │ │ Payment │ │ Logistics │ │ Service │ │ Service │ │ Service │ │ Subscribe │ │ Subscribe │ │ Subscribe │ │ order events│ │ order events│ │ order events│ └──────────────┘ └──────────────┘ └──────────────┘

3.3 The Essence of Decoupling: From "Direct Calls" to "Event-Driven"3.3 The Essence of Decoupling: From "Direct Calls" to "Event-Driven"

Paradigm shift:Paradigm shift:

Traditional thinking (imperative): "Order service commands inventory service: Deduct inventory for me!" ↓ Direct call ↓ High coupling, callee must be online ↓ Caller needs to know callee's interface Event-driven thinking (declarative): "Order service declares: Order has been created. Whoever cares, handle it." ↓ Send event to message queue ↓ Decoupled, consumers can be offline ↓ Producer doesn't need to know consumers exist

------

4. Core Problem 2: Approach to handling Traffic Spikes with Peak Shaving4. Core Problem 2: Approach to handling Traffic Spikes with Peak Shaving

4.1 Flash Sale Scenario: Approach to handling 100K QPS Smoothly4.1 Flash Sale Scenario: Approach to handling 100K QPS Smoothly

Scenario recreation: An e-commerce platform's Double 11 flash sale, expected peak 100K QPS, but the database can only handle 1,000 QPS.Scenario recreation: An e-commerce platform's Double 11 flash sale, expected peak 100K QPS, but the database can only handle 1,000 QPS.

Consequences of direct impact:Consequences of direct impact:

User requests ──→ App server ──→ Database 100K/s 100K/s 1K/s (limit) ↓ Connection pool exhausted Response timeout Database crash ↓ Cascading failure (all services depending on DB go down)

4.2 Peak Shaving Solution: Message Queue as "Reservoir"4.2 Peak Shaving Solution: Message Queue as "Reservoir"

Architecture design:Architecture design:

┌───────────────────────────────────────────────────────────────────────┐ │ Flash Sale System Architecture │ ├───────────────────────────────────────────────────────────────────────┤ │ │ │ Layer 1: Gateway (hard rate limiting) │ │ ┌───────────────────────────────────────────────────────────────┐ │ │ │ - Token bucket: 100K/s → 10K/s (drop 90% of requests) │ │ │ │ - CDN caches static resources (product detail pages) │ │ │ │ - CAPTCHA / queue page (first layer of peak shaving) │ │ │ └───────────────────────────────────────────────────────────────┘ │ │ │ │ │ ▼ │ │ Layer 2: Service (soft rate limiting) │ │ ┌───────────────────────────────────────────────────────────────┐ │ │ │ - Nginx rate limiting: 10K/s → 5K/s │ │ │ │ - Redis pre-deduct inventory (atomic operation): │ │ │ │ * Use Lua script for atomicity │ │ │ │ * Insufficient stock → return "Sold out" directly │ │ │ │ - Generate order token (queue voucher) │ │ │ └───────────────────────────────────────────────────────────────┘ │ │ │ │ │ ▼ │ │ Layer 3: Message Queue (core peak shaving) │ │ ┌───────────────────────────────────────────────────────────────┐ │ │ │ Kafka/RocketMQ: │ │ │ │ - Batch write: 5K/s → 1K/s (matching DB capacity) │ │ │ │ - Message persistence: disk write guarantees no message loss │ │ │ │ - Multi-partition parallel consumption: boost throughput │ │ │ │ - Consumer offset management: support failure recovery │ │ │ │ │ │ │ │ Key metrics monitoring: │ │ │ │ - Produce Rate │ │ │ │ - Consume Rate │ │ │ │ - Lag (message backlog) │ │ │ └───────────────────────────────────────────────────────────────┘ │ │ │ │ │ ▼ │ │ Layer 4: Consumer (async processing) │ │ ┌───────────────────────────────────────────────────────────────┐ │ │ │ Order processing consumers (multiple instances): │ │ │ │ - Pull messages from Kafka (1K/s, matching DB capacity) │ │ │ │ - DB transaction: create order + deduct inventory │ │ │ │ - Update order status to "Created" │ │ │ │ - Send order creation success notification (email/SMS/push) │ │ │ │ - Confirm message consumption (ACK) │ │ │ │ │ │ │ │ Consumer scaling strategy: │ │ │ │ - When Lag > 10,000, auto-scale up consumer instances │ │ │ │ - When Lag < 1,000, scale down consumer instances (save cost) │ │ │ └───────────────────────────────────────────────────────────────┘ │ │ │ └───────────────────────────────────────────────────────────────────────┘

4.3 Mathematical Principles of Peak Shaving4.3 Mathematical Principles of Peak Shaving

Traffic smoothing effect:Traffic smoothing effect:

Original traffic (spike): Smoothed traffic: 100K/s │ ╱╲ 1K/s │████████████████ │ ╱ ╲ │ │ ╱ ╲ │ 1K/s│╱ ╲ 0/s │ └─────────────── └──────────────── 0s 1s 2s 0s 20s Original: 100K/s peak, lasting 1 second Smoothed: 1K/s constant rate, lasting 100 seconds

Key formulas:Key formulas:

Queue length = Producer rate × Duration - Consumer rate × Duration = 100,000 × 1 - 1,000 × 1 = 99,000 messages (peak queue backlog) Time to consume all messages = Queue length / Consumer rate = 99,000 / 1,000 = 99 seconds

------

5. Core Problem 3: Approach to ensuring Messages Are Not Lost, Not Duplicated, and In Order5. Core Problem 3: Approach to ensuring Messages Are Not Lost, Not Duplicated, and In Order

5.1 Message Reliability: Three Lines of Defense5.1 Message Reliability: Three Lines of Defense

Messages can be lost at three stages: during producer sending, during Broker storage, and during consumer processing.Messages can be lost at three stages: during producer sending, during Broker storage, and during consumer processing.

5.2 Approach to handling Duplicate Message Consumption5.2 Approach to handling Duplicate Message Consumption

Message duplication can occur in the following scenarios:Message duplication can occur in the following scenarios:

1. Producer retry: Producer sends message but doesn't receive ACK, retries sending the same messageProducer retry: Producer sends message but doesn't receive ACK, retries sending the same message
2. Consumer ACK timeout: Consumer finishes processing but ACK times out, Broker redeliversConsumer ACK timeout: Consumer finishes processing but ACK times out, Broker redelivers
3. Network jitter: Consumer ACK doesn't reach Broker, Broker considers message unconsumedNetwork jitter: Consumer ACK doesn't reach Broker, Broker considers message unconsumed
4. Consumer restart: After consumer restarts, re-consumes the same batch of messagesConsumer restart: After consumer restarts, re-consumes the same batch of messages
💡 Tips Praktis💡 Pro Tip

Idempotency: Executing the same operation multiple times produces the same result as executing it once. Everyday idempotency examples: - Idempotent: Pressing an elevator button (pressing 10 times or once, the elevator still comes) - Non-idempotent: Bank transfer (transferring $10, executing twice transfers $20) Technical solution: Generate a unique ID for each message; check if already processed before handling.Idempotency: Executing the same operation multiple times produces the same result as executing it once. Everyday idempotency examples: - Idempotent: Pressing an elevator button (pressing 10 times or once, the elevator still comes) - Non-idempotent: Bank transfer (transferring $10, executing twice transfers $20) Technical solution: Generate a unique ID for each message; check if already processed before handling.

------

6. Practice: Approach to choosing a Message Queue6. Practice: Approach to choosing a Message Queue

6.1 Comparison of Four Mainstream Message Queues6.1 Comparison of Four Mainstream Message Queues

Feature	RabbitMQ	Kafka	RocketMQ	Redis Stream
Positioning	Traditional MQ	Distributed log stream	E-commerce-grade MQ	Lightweight queue
Throughput	~10K/s	~1M/s	~100K/s	~50K/s
Latency	Microseconds	Milliseconds	Milliseconds	Milliseconds
Reliability	High (persistence)	High (multi-replica)	High (sync flush)	Medium (AOF)
Message replay	Not supported	Supported	Supported	Supported
Transactional messages	Supported (weak)	Not supported	Supported (strong)	Not supported
Delayed messages	Supported	Not supported	Supported	Not supported
Use cases	Traditional enterprise apps	Logs, big data	E-commerce, finance	Small-scale apps

💡 Tips Praktis💡 Pro Tip

Decision tree: `` Choosing a message queue: │ ├─ Need transactional messages (distributed transactions)? │ ├─ Yes → RocketMQ (first choice) or RabbitMQ │ └─ No → continue │ ├─ Need to process massive logs/real-time streams? │ ├─ Yes → Kafka (first choice) │ └─ No → continue │ ├─ QPS > 10K/s? │ ├─ Yes → RocketMQ or Kafka │ └─ No → continue │ ├─ Need complex routing (e.g., header matching)? │ ├─ Yes → RabbitMQ │ └─ No → continue │ ├─ Already have Redis infrastructure? │ ├─ Yes → Redis Stream (quick start) │ └─ No → RabbitMQ (full-featured, moderate learning curve) ``Decision tree: `` Choosing a message queue: │ ├─ Need transactional messages (distributed transactions)? │ ├─ Yes → RocketMQ (first choice) or RabbitMQ │ └─ No → continue │ ├─ Need to process massive logs/real-time streams? │ ├─ Yes → Kafka (first choice) │ └─ No → continue │ ├─ QPS > 10K/s? │ ├─ Yes → RocketMQ or Kafka │ └─ No → continue │ ├─ Need complex routing (e.g., header matching)? │ ├─ Yes → RabbitMQ │ └─ No → continue │ ├─ Already have Redis infrastructure? │ ├─ Yes → Redis Stream (quick start) │ └─ No → RabbitMQ (full-featured, moderate learning curve) ``

------

7. Summary: Message Queue Design Principles7. Summary: Message Queue Design Principles

7.1 Core Principles Review7.1 Core Principles Review

Principle	Meaning	Practice Points
Decoupling	Services don't directly depend on each other	Communicate via message queue; consumer failure doesn't affect producer
Peak shaving	Smooth traffic fluctuations	Message queue as reservoir; consumers process at constant rate
Reliability	Messages not lost	Producer ACK + Broker persistence + Consumer ACK
Idempotency	Duplicate consumption has no effect	Business-level idempotency guarantees (unique keys, state machines)
Ordering	Message order guarantee	Single-partition ordering or consumer-side sorting

7.2 Design Checklist7.2 Design Checklist

Before introducing a message queue, ask yourself:Before introducing a message queue, ask yourself:

• [ ] Do you really need a message queue? (Simple async can use thread pools)[ ] Do you really need a message queue? (Simple async can use thread pools)
• [ ] Is message loss acceptable? (Determines reliability level)[ ] Is message loss acceptable? (Determines reliability level)
• [ ] Will message duplication affect the business? (Determines idempotency investment)[ ] Will message duplication affect the business? (Determines idempotency investment)
• [ ] Is message order important? (Determines partition strategy)[ ] Is message order important? (Determines partition strategy)
• [ ] What's the consumer processing capacity? (Determines queue size and alert thresholds)[ ] What's the consumer processing capacity? (Determines queue size and alert thresholds)
• [ ] How to handle consumption failures? (Determines retry and dead letter strategies)[ ] How to handle consumption failures? (Determines retry and dead letter strategies)

------

8. Glossary8. Glossary

Term	Full Name	Description
MQ	Message Queue	Middleware for asynchronous communication, decoupling producers and consumers.
Producer	-	The party that sends messages.
Consumer	-	The party that receives and processes messages.
Broker	-	The server program that stores and forwards messages.
Topic	-	Logical categorization of messages (e.g., "orders").
Queue	-	Physical container storing messages.
Partition	-	A Kafka concept; one Topic can be split into multiple Partitions for higher concurrency.
ACK	Acknowledgment	Consumer confirms to Broker after processing a message.
Pub/Sub	Publish/Subscribe	A messaging pattern where one message can be received by multiple consumers.
P2P	Point-to-Point	A messaging pattern where one message can only be received by one consumer.
DLQ	Dead Letter Queue	Stores messages that cannot be consumed.
Idempotence	-	Multiple executions produce the same result.
Throughput	-	Number of messages processed per unit time.
Latency	-	Time difference from message send to receipt.
Persistence	-	Messages written to disk, not just stored in memory.
Replication	-	Messages copied to multiple nodes for high availability.
Transaction Message	-	Guarantees consistency between local transaction and message sending.
Backpressure	-	When consumers can't keep up, they notify producers to slow down.
Offset	-	The consumer's consumption position within a partition.
Rebalance	-	Reassigning partitions when consumer group members change.

← SebelumnyaPrevious4-server-and-backend/http-protocol4-server-and-backend/http-protocol SelanjutnyaNext →4-server-and-backend/rate-limiting-backpressure4-server-and-backend/rate-limiting-backpressure