Saga Pattern: Distributed Transactions Without 2PC

Prerequisite: Familiarity with the concepts introduced in Part 3 — Event Sourcing Cqrs. Review it first if the terminology in this part is unfamiliar. Answer-first: The Saga pattern coordinates distributed transactions across core banking microservices without two-phase commit (2PC). By executing local transactions and defining compensating actions for failures, Sagas ensure eventual consistency across payment and ledger services. Series (Part 4 of 8): This article builds upon Event Sourcing from Part 3. The Saga Pattern solves the problem: “How do we ensure consistency when a transaction must coordinate across multiple microservices without using distributed locks or 2PC?” ...

June 18, 2026 · 13 min · Lê Tuấn Anh

Consistent Hashing in Go — Virtual Nodes & CRC32 Ring

Answer-first: Consistent Hashing minimizes key remapping when cluster membership changes. Adding or removing one node from a modulo-hash cluster remaps nearly all keys (catastrophic cache miss storm). Consistent Hashing remaps only $K/N$ keys — the theoretical minimum necessary. Prerequisite: Part 9 of the System Design Masterclass. Read Part 4: Database Scaling for context on horizontal partitioning strategies. What You’ll Learn Virtual Node Standard Deviation: The exact mathematical variance drop when increasing virtual node count ($V$) from 1 to 1000. RWMutex Lock Contention: Why using sync.RWMutex on the hash ring can cause lock contention under high multi-core throughput, and how to optimize with atomic values. CRC32 vs Murmur3: Why the choice of hashing algorithm on the ring impacts lookup distribution uniformity. Why Modulo Hashing Fails When Scaling Key Concept: hash(key) % N changes to hash(key) % (N+1) when a node is added, causing nearly all key-to-node mappings to change. This creates a massive cache miss storm as the entire working set must be reloaded from the database simultaneously. ...

June 18, 2026 · 9 min · Lê Tuấn Anh

Go System Design: CAP, PACELC & Clean Architecture Primer

Prerequisite: This is Part 1 of the System Design Masterclass series. Familiarity with basic distributed systems concepts and Go syntax is assumed. Go System Design: CAP, PACELC & Clean Architecture Primer Answer-first: System design in Go balances CAP/PACELC trade-offs across consistency, availability, and latency. Clean Architecture isolates business logic behind Go interfaces while dependency injection decouples domain layers from database and transport protocols. Key Takeaways: CAP Theorem: Network partitions force an absolute choice between Consistency (CP) and Availability (AP). PACELC Matrix: When normal operation occurs (else), systems trade off Latency (L) versus Consistency (C). Clean Architecture: Domain interfaces isolate business logic from SQL/gRPC infrastructure, enabling unit testing without mocks. What You’ll Learn CAP Theorem Realities: A rigorous look at Gilbert and Lynch’s proof showing why network partitions force an absolute choice between availability and consistency. PACELC in Practice: Why latency-consistency trade-offs are the real bottleneck in healthy networks, and how Go services suffer under Spanner’s commit wait times. Clean Architecture Cost: The compilation and memory allocation overhead of interface-driven design in Go. How Do You Build System Design Thinking? Answer-first: System design thinking relies on evaluating 3D performance-reliability-cost trade-offs, calculating composite availability math ($A_{\text{composite}} = A_A \times A_B \times A_C$), and establishing strict SLI metrics, SLO targets, and SLA contracts. ...

June 18, 2026 · 10 min · Lê Tuấn Anh

Alipay Double 11: 544,000 TPS Architecture Explained

Alipay Double 11: 544,000 TPS Architecture Explained Research Baseline Two different Double 11 peak figures circulate widely, and they measure different layers of the stack — conflating them is the most common error in write-ups on this topic: Figure What it actually measures Layer Source 544,000 TPS Alipay payment transactions per second (2019) Payment / ledger OceanBase engineering 61 million QPS Database queries per second at the same 2019 peak Database OceanBase engineering 583,000 orders/sec Order creation on Alibaba’s e-commerce platform (2020) Commerce / order intake Alibaba Group press release [!IMPORTANT] The widely-quoted 583,000 figure is order creation throughput on Alibaba’s commerce platform, not Alipay’s payment TPS. Alipay’s reported payment peak is 544,000 TPS. This article is about the payment-side architecture, so 544,000 TPS is the relevant number. ...

June 1, 2026 · 6 min · Lê Tuấn Anh

Dapr State Store Consistency Trade-offs Explained

Dapr State Store Consistency Trade-offs Explained Dapr State Store Architecture & Consistency Models In distributed applications, state management remains one of the most complex challenges. When transitioning to a microservices architecture, each service typically requires independent data storage and querying capabilities. This leads to technology fragmentation, where a system might simultaneously use Redis for caching, PostgreSQL for transactional data, and Cassandra for large unstructured data. Dapr (Distributed Application Runtime) emerged to solve this issue through a robust abstraction mechanism. ...

May 22, 2026 · 14 min · Lê Tuấn Anh