Part 2: Event-Driven Architecture — Kafka at Scale, Transactional Outbox & Idempotency

Multi-Language Edition: This chapter is also available in Vietnamese at 📖 Bản tiếng Việt (Vietnamese Edition). Previous Chapter: Part 1 — Microservices & GitOps Blueprint | Series Hub | Next Chapter: Part 3 — Data Infrastructure: From Aurora to TiDB Answer-First: Handling sudden promotional payment spikes of thousands of TPS requires complete decoupling of synchronous ingress requests from asynchronous ledger persistence. PayPay implements an Event-Driven Architecture centered on Apache Kafka. To guarantee zero financial discrepancies between the database and event streams, PayPay utilizes the Transactional Outbox Pattern with Debezium CDC, avoiding dual-write race conditions. Downstream consumer microservices enforce strict idempotency via Redis distributed locks and UUIDv7 idempotency keys, paired with isolated Dead Letter Queues (DLQ) to prevent poisoned payloads from blocking partition processing. ...

Part 9: Transactional Outbox & Distributed Sagas in Composable Commerce

← Previous Chapter: Part 8: Phase 3 — Full Cutover | Series Hub | Next Chapter: Part 10: ADR Walkthrough — 24 Architecture Decisions → Answer-first: In a distributed e-commerce architecture without 2-Phase Commit (2PC), distributed consistency is achieved via the Transactional Outbox Pattern (saving domain events in the same SQL ACID transaction as business state) and Orchestrated Sagas (executing compensating transactions upon payment or inventory failure). sequenceDiagram autonumber actor Customer as Customer participant Order as Order Service (Saga Orchestrator) participant Inventory as Inventory Service participant Payment as Payment Service Customer->>Order: Create Order Order->>Order: Save Order (PENDING) + Outbox Event (Atomic ACID) Order->>Inventory: Reserve Stock (gRPC) alt Inventory Available Inventory-->>Order: Stock Reserved OK Order->>Payment: Authorize Payment (gRPC) alt Payment Succeeded Payment-->>Order: Payment Captured OK Order->>Order: Update Order (CONFIRMED) Order-->>Customer: Order Placed Successfully! else Payment Failed Payment-->>Order: Card Declined Order->>Inventory: Compensating Tx: Release Reserved Stock Order->>Order: Update Order (CANCELLED) Order-->>Customer: Payment Failed end else Out of Stock Inventory-->>Order: Insufficient Stock Order->>Order: Update Order (CANCELLED) Order-->>Customer: Item Out of Stock end

Banking Microservices in Go: Saga & Event Sourcing

Banking Microservices in Go: Saga & Event Sourcing Answer-first: Banking microservices architecture enforces strict domain isolation, dual-entry accounting ledgers, immutable audit logging, and SPIFFE/SPIRE zero-trust mTLS to maintain high transaction throughput and financial compliance. 1. Introduction: Deconstructing the Legacy Core Legacy banking platforms like Temenos T24 and Oracle FLEXCUBE were designed as rigid transactional monoliths for batch processing. Digital banking now requires decomposing these into event-driven microservices capable of real-time payments with sub-10ms latency. ...