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

Previous Chapter: Part 1 — Microservices & GitOps Blueprint | Series Hub | Next Chapter: Part 3 — Data Infrastructure: From Aurora to TiDB Answer-first: PayPay guarantees zero event loss and strict ledger decoupling under promotional surges exceeding 1,250 TPS by combining the Transactional Outbox pattern with Debezium CDC and Apache Kafka. Consumer groups utilize the CooperativeStickyAssignor to prevent rebalance stop-the-world pauses, while a two-stage Redis distributed lock provides exactly-once processing semantics before persisting updates into the database. ...

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. ...