PayPay Event-Driven Architecture: Kafka at Scale

Executive Summary & Quick Answer: Managing transaction surges during PayPay’s massive marketing campaigns requires event-driven architecture powered by Apache Kafka. Partition key tuning, Go consumer worker pools, and channel-based backpressure prevent message loss during peak traffic spikes. Answer-First: PayPay builds a decoupled microservices network by streaming transactions asynchronously via Apache Kafka. To ensure financial safety, consumers process events using idempotency keys tracked in distributed caches, preventing duplicate ledger entries or double-spend occurrences in the event of retries or network partition splits. ...

May 5, 2026 · 8 min · Lê Tuấn Anh

Transactional Outbox & Saga Pattern for E-commerce

Answer-First: Distributed transaction consistency is achieved using a choreography-based saga paired with a PostgreSQL transactional outbox. Business mutations write to the outbox atomically. Background workers publish events to Dapr PubSub every 500ms, while idempotent consumer handlers process compensation events on failure. When a customer places an order on the Composable Commerce Platform, seven events need to happen in sequence across four independent services: Order created → Payment authorized → Stock reserved → Fulfillment triggered → Notification sent → Loyalty points awarded → Shipping label generated. Any of these can fail. The network can fail. The database can fail. A third-party payment gateway can time out. ...

June 3, 2026 · 16 min · Lê Tuấn Anh

Distributed Transactions in Go with Temporal Saga Pattern

Distributed Transactions in Go with Temporal Saga Pattern Answer-First: Distributed transactions in Go microservices are best implemented using the Temporal Saga pattern, replacing blocking Two-Phase Commit (2PC) locks with imperative workflow orchestration, dynamic reverse compensations (saga.AddCompensation), and PostgreSQL idempotency tables to guarantee financial event consistency during network partitions. Key Takeaways: Fault-Tolerant Orchestration over Choreography: Temporal replaces fragile event-driven “event soup” with deterministic event histories. Tail latencies drop, and debugging distributed state machines transforms from distributed trace stitching to reading a unified workflow history log. Dual-Entry Invariant Protection via Reverse Compensations: By executing backward compensation routines registered dynamically via saga.AddCompensation, failed financial transfers automatically issue compensating refunds with sub-second execution once downstream failures are confirmed. Production-Grade Idempotency & Heartbeating: Combining PostgreSQL unique idempotency keys (idempotency_keys table with SELECT FOR UPDATE) with Temporal’s HeartbeatTimeout and activity.RecordHeartbeat guarantees zero duplicate debits during activity worker retries or network split-brain scenarios. The Zombie Activity Pitfall: Why setting StartToCloseTimeout without database-level idempotency locks causes phantom debits during prolonged TCP network partitions. Dynamic Compensation Registration: How to structure workflow.NewSaga in Go so that partial failures (e.g., debit succeeds, fraud check passes, but ledger credit fails) only execute compensation for steps that actually mutated state. Handling Non-Compensable External Side-Effects: Practical design patterns for handling third-party banking APIs (e.g., SWIFT/ACH wires) that cannot be programmatically rolled back. Workflow Determinism Invariants: How to write Go workflows that use Temporal signals and queries without triggering fatal non-deterministic replay panic errors. Section 1: FinTech Distributed Transaction Mechanics: 2PC vs Saga & Dual-Entry Accounting Invariants In modern distributed financial systems, microservice architectures decompose monoliths into autonomous domains: Account Management, Fraud Detection, Core Ledger, Payment Gateway Integration, and Customer Notifications. While this decomposition provides organizational velocity and independent database scaling, it shatters the traditional ACID guarantees provided by single-instance relational databases. ...

July 23, 2026 · 24 min · Lê Tuấn Anh

Shopee DB: MySQL Sharding to TiDB NewSQL Migration

Answer-First: Shopee scales its relational database layer past single-node MySQL limits by migrating to TiDB Distributed SQL. By separating stateless SQL compute (TiDB) from stateful key-value storage (TiKV) and columnar analytics (TiFlash), TiDB delivers transparent horizontal auto-sharding and ACID transactions without application-level sharding logic. Chapter 4: Database Scale - The Rise of TiDB and NewSQL ← Series hub | ← Prev | Next → Prerequisite: Read the previous article: Chapter 3: Traffic Shield - Peak Shaving with Kafka and Graceful Degradation. ...

May 5, 2026 · 8 min · Lê Tuấn Anh

Alipay Double 11 Architecture: LDC & Unitization Guide

← Series hub ← Prev • Next → Executive Summary & Quick Answer: Alipay’s Logical Data Center (LDC) unitization architecture partitions database tables and application servers into self-contained “RZone” units based on user ID hashes. This multi-active setup bounds failure blast radiuses and allows horizontal scaling across multiple data centers. Prerequisite: Phase 1: Timeline and Scale Evolution This phase focuses on the architectural blueprint that enables planetary scaling while preserving absolute transactional correctness and operational control. The core design philosophy is: scale through containment, not coordination. ...

May 2, 2026 · 9 min · Lê Tuấn Anh

Alipay Double 11 Technology Internals Deep-Dive Guide

← Series hub ← Prev • Next → Executive Summary & Quick Answer: Alipay’s Double 11 technology deep dive reveals high-performance internals: binary Bolt RPC protocol multiplexing over single TCP streams, RocketMQ 2PC transactional messaging for async decoupling, OceanBase LSM-tree compaction tuning, and multi-zone Paxos quorum consensus to achieve 544,000 TPS payment processing. Prerequisite: Phase 4: Technology Overview This document is a deep-dive companion to Phase 4. It focuses on the internal mechanics that define the hard limits of peak performance systems: RPC protocol layouts, consensus log replication pipelines, storage engine compaction configurations, and distributed transactions. ...

May 2, 2026 · 10 min · Lê Tuấn Anh