🎯 Core Architecture Style Framework
When discussing event-driven vs request-response architectures, I frame it as:
- Interaction model: synchronous vs asynchronous
- System goals: control vs decoupling
- Trade-offs: latency, consistency, and complexity
- Real-world hybrid architectures
1️⃣ Request-Response Architecture
Definition
- Client sends request → waits for response
- Synchronous interaction
Strengths
- Simple mental model
- Strong consistency
- Easier debugging
Limitations
- Tight coupling
- Latency accumulates across services
- Failure propagation
👉 Interview Answer
Request-response is a synchronous interaction model where a client waits for a response before proceeding. It’s simple and provides strong consistency, but creates tight coupling and can increase latency across multiple services.
Best Fit
- User-facing APIs
- Strong consistency requirements
- Immediate feedback needed
👉 Interview Answer
I typically use request-response for user-facing operations that require immediate feedback and strong consistency, such as login or payment flows.
2️⃣ Event-driven Architecture
Definition
- Producer emits event → consumers process asynchronously
Strengths
- Loose coupling
- High scalability
- Failure isolation
Limitations
- Eventual consistency
- Harder debugging
- Complex flow tracing
👉 Interview Answer
Event-driven architecture is asynchronous, where services communicate through events instead of direct calls. It improves scalability and decoupling, but introduces eventual consistency and makes debugging more complex.
Best Fit
- Background processing
- Event propagation
- Large-scale systems
👉 Interview Answer
I use event-driven architecture for background tasks, event propagation, and systems that need to scale independently, such as notifications or analytics pipelines.
3️⃣ Core Trade-offs
Latency
- Request-response → immediate but accumulates
- Event-driven → delayed but scalable
👉 Interview Answer
Request-response provides immediate results but latency adds up across service calls, while event-driven systems introduce delay but allow better scalability and decoupling.
Coupling
- Request-response → tight
- Event-driven → loose
👉 Interview Answer
Request-response tightly couples services, whereas event-driven systems decouple producers and consumers, allowing independent evolution and scaling.
Consistency
- Request-response → strong
- Event-driven → eventual
👉 Interview Answer
Request-response is better for strong consistency, while event-driven systems typically rely on eventual consistency, which requires handling stale data and conflicts.
Failure Handling
- Request-response → propagates failure
- Event-driven → isolates failure
👉 Interview Answer
In request-response systems, failures propagate upstream, while in event-driven systems, failures are isolated, since messages can be retried or processed later.
Summary Table
| Aspect | Request-Response | Event-driven |
|---|---|---|
| Latency | Immediate | Delayed |
| Coupling | Tight | Loose |
| Consistency | Strong | Eventual |
| Failure | Propagates | Isolated |
| Complexity | Lower | Higher |
👉 Interview Answer（总结一句）
Request-response optimizes for control and simplicity, while event-driven architecture optimizes for scalability and resilience.
4️⃣ Real-world Hybrid Architecture
Pattern 1: Sync for critical path, async for side effects
Client → API → DB
↓
Event → Queue → Workers
👉 Interview Answer
In practice, I use request-response for the critical path, and event-driven architecture for side effects like notifications or analytics. This keeps the system responsive while maintaining scalability.
Pattern 2: Event-driven backbone
- Services communicate via events
- API layer still synchronous
👉 Interview Answer
Many modern systems use an event-driven backbone internally, while exposing synchronous APIs externally, combining the benefits of both models.
Pattern 3: Saga pattern (distributed transactions)
👉 Interview Answer
In distributed systems, I use event-driven patterns like sagas to coordinate multi-step workflows, ensuring eventual consistency without requiring distributed transactions.
Pattern 4: CQRS (Command Query Responsibility Segregation)
👉 Interview Answer
CQRS separates write and read paths, often combining synchronous writes with asynchronous read model updates, which improves scalability and performance.
🧠 Staff-Level Answer (Final Polished)
👉 Interview Answer（完整背诵版）
When choosing between request-response and event-driven architectures, I consider the trade-off between control and decoupling. Request-response provides strong consistency and immediate feedback, but introduces tight coupling and latency accumulation. Event-driven architecture improves scalability and resilience, but introduces eventual consistency and higher complexity.
In practice, most systems use a hybrid approach, where the critical path is handled synchronously, and side effects are processed asynchronously through events.
The decision depends on whether the system prioritizes immediacy and correctness, or scalability and fault isolation.
⭐ Staff-Level Insight（拉开差距）
👉 Interview Answer
The key difference is control: request-response gives you control over execution, while event-driven systems give you control over scalability.
中文速背版（Staff级）
Request-response
同步 → 强一致 → 简单但耦合高
Event-driven
异步 → 可扩展 → 但复杂 + 最终一致
核心对比
控制 vs 解耦
实际系统
关键路径同步 + 副作用异步
一句话总结
同步保证结果，异步保证规模
下一步
👉 “Event-driven 深挖：ordering / exactly-once / Kafka vs MQ / stream processing”
Implement