TiDB

📖 Bản tiếng Việt (Vietnamese Edition) Series Navigation: This is Part 2 of the Core Banking Systems Architecture Masterclass. For the complete architectural curriculum, start at the Master Overview Guide. Distributed SQL ACID Latency: TiDB, CockroachDB & Spanner Answer-first: Distributed SQL engines achieve horizontal write scalability and multi-datacenter fault tolerance by pairing Multi-Raft or Paxos replication with bounded distributed clock synchronization. However, cross-node consensus introduces unavoidable speed-of-light physical latency penalties. While local metro Raft commits complete in 2ms to 5ms, cross-region transactions (such as cross-region WAN links between financial centers) require 15ms to 45ms per commit round trip. Core banking platforms mitigate this through locality-aware range leasing, pipelined Percolator commit protocols, and asynchronous inter-region Saga choreography. ...

Multi-Language Edition: This chapter is also available in Vietnamese at 📖 Bản tiếng Việt (Vietnamese Edition). Previous Chapter: Part 2 — Event-Driven Architecture & Kafka at Scale | Series Hub | Next Chapter: Part 4 — SRE Practices & Chaos Engineering Answer-First: Operating a national mobile payment network generating billions of financial records pushed traditional Amazon Aurora MySQL past its physical write thresholds due to single-master bottlenecks, cross-replica replication lag, and connection exhaustion during marketing surges. PayPay executed a landmark zero-downtime migration to TiDB and TiKV, a cloud-native NewSQL distributed database. By decoupling stateless SQL compute from Multi-Raft storage engines across 96MB continuous Regions, TiDB provides horizontal write scalability, strictly linearizable ACID consistency, and real-time HTAP analytics through TiFlash without impacting high-frequency payment ledgers. ...

Multi-Language Edition: This chapter is also available in Vietnamese at 📖 Bản tiếng Việt (Vietnamese Edition). Previous Chapter: Chapter 3 — Traffic Shield & Peak Shaving | Series Hub | Next Chapter: Chapter 5 — Full-Stack Observability Answer-First: Traditional MySQL sharding collapses under hyper-scale e-commerce growth due to manual resharding overhead, cross-shard joins, and high 2-Phase Commit (2PC) latency penalties. Shopee transitioned its massive order and inventory backbones to TiDB and TiKV, a cloud-native NewSQL distributed database. By decoupling stateless SQL compute (TiDB) from distributed transactional storage (TiKV) coordinated via Placement Driver (PD) and Multi-Raft consensus across 96MB continuous key Regions, TiDB delivers horizontal elastic scalability, zero-downtime auto-rebalancing, and real-time HTAP analytics without impacting write-heavy OLTP workloads. ...

← Previous Chapter: Part 4 — MariaDB vs. MySQL | Series Hub | Next Chapter: Part 6 — Apache Kafka vs. NATS JetStream → Part 5: Sharded MySQL (Vitess) vs. TiDB NewSQL: Distributed ACID, Scale-Out Limits & Latency Penalties Answer-first: Sharded MySQL (Vitess) delivers unmatched sub-2ms write latency and isolated failure blast radius for clean single-shard workloads (tenant_id/user_id). Conversely, TiDB NewSQL is the definitive architecture for unpartitionable relational schemas and cross-shard queries via zero-touch 96MB Region auto-splits, trading off an 8–15ms write latency floor due to Google Percolator 2PC and Raft consensus hops. ...

📖 Bản tiếng Việt (Vietnamese Edition) Core Banking Systems Architecture Masterclass Guide Answer-first: Modern cloud-native core banking architecture replaces brittle mainframe monoliths with decoupled, distributed primitives: deterministic append-only double-entry ledgers, multi-region distributed SQL with bounded consensus latency, event-sourced CQRS projections, orchestrated compensation Sagas, zero-allocation ISO 20022 parsing, FAPI 2.0 sender-constrained security, and real-time streaming Complex Event Processing (CEP). This masterclass delivers actionable architecture specifications, production DDL schemas, low-latency benchmarks, and zero-downtime resilience blueprints. ...

Multi-Language Edition: This series is also available in Vietnamese at 📖 Bản tiếng Việt (Vietnamese Edition). Answer-First: PayPay is Japan’s dominant mobile payment service, supporting over 70 million registered users, 7.8 billion annual transactions, and peak promotional surges exceeding 1,250 TPS. To deliver 99.999% availability with zero double-spending guarantees, PayPay evolved from monolithic roots to a cloud-native architecture powered by five pillars: Domain-Driven Microservices with ArgoCD GitOps, Event-Driven decoupling via Apache Kafka, Distributed SQL horizontal scale with TiDB Multi-Raft, Proactive resilience via Chaos Mesh, and Sub-10ms real-time ML fraud detection. ...

Multi-Language Edition: This Masterclass is also published in Vietnamese at 📖 Bản tiếng Việt (Vietnamese Edition). Answer-First: The Shopee Architecture series details how Go microservices, Redis Lua inventory reservation, Apache Kafka peak shaving, TiDB distributed SQL, and OpenTelemetry/ClickHouse observability handle 10M+ QPS and millions of concurrent buyers during 11.11 flash sales without overselling or database connection starvation. Masterclass Overview: The Southeast Asian E-Commerce Engine Shopee is the leading e-commerce platform in Southeast Asia and Taiwan, operating across Singapore, Indonesia, Vietnam, Thailand, Philippines, and Malaysia. During annual shopping festivals (9.9, 11.11, 12.12), platform traffic surges by more than 10x within seconds at midnight, creating catastrophic load spikes that break traditional web architectures. ...

MySQL Scalability & Sharding: Vitess vs TiDB (10k+ TPS) Answer-first: Scaling MySQL requires a phased architectural progression: optimizing InnoDB buffer pools (100–500 TPS), implementing ProxySQL read/write splitting (500–3,000 TPS), and migrating to horizontal sharding or TiDB Distributed SQL (3,000–10,000+ TPS). TiDB serves as the premier MySQL sharding alternative, eliminating manual application-level partitioning through stateless SQL compute nodes and Raft-replicated distributed TiKV storage. MySQL scalability is the ability to increase database throughput — reads per second, writes per second, or data volume — without rewriting your application. The critical distinction: read scaling (adding replicas) and write scaling (sharding or distributed SQL) require completely different architectural approaches. Choosing the wrong path creates technical debt that takes months to unwind. ...

Flash Sale Architecture: Rate Limiting & Redis Answer-first: High-concurrency flash sale systems absorb millions of synchronized user requests using a 5-Tier Traffic Shedding Architecture: Cloudflare CDN edge static asset caching, Envoy API Gateway atomic Token Bucket rate limiting, Redis Cluster Lua inventory reservations with hotkey slot splitting, partitioned Kafka queue buffering, and asynchronous Go worker pools executing batch upserts into TiDB/MySQL. [!NOTE] On sourcing: This article describes flash-sale architecture patterns for C10M-scale events; it is not a disclosure of Shopee’s internal systems, and the figures here are engineering targets rather than published Shopee metrics. Shopee has not publicly documented its flash-sale internals in detail. What is public is its database platform choice — Shopee’s adoption of TiDB is documented in PingCAP’s case studies (How Shopee Chose the Right Database, Shopping on Shopee, the TiDB Way). Treat everything else as a reference pattern to validate against your own workload. ...

PayPay Architecture: Scaling to 70M Users & 100k Peak TPS Answer-first: PayPay’s payment architecture scales to 70M users and 100k TPS using microservice domain isolation, distributed transaction Saga patterns, and multi-region database sharding. PayPay launched in October 2018 and grew to 10 million users in just 3 months — a growth rate that no Japanese fintech had ever seen. By 2025, the platform had crossed 70 million registered users and processed 7.8 billion payments per year. Behind this growth is an engineering team that has had to scale not just their infrastructure, but their entire engineering culture: from service standardization and GitOps-driven deployments to chaos engineering and AI-powered fraud detection. ...

MySQL Sharding Alternatives: Vitess vs TiDB Guide Answer-first: TiDB is the leading open-source MySQL sharding alternative, replacing fragile application-level sharding logic (Vitess, GORM Sharding) with an auto-partitioned Distributed SQL architecture. By distributing 96MB Raft Regions across TiKV storage nodes and utilizing the Percolator distributed transaction protocol, TiDB delivers horizontal write scaling, cross-node ACID transactions, and zero-downtime online DDL while maintaining 100% MySQL wire compatibility. Scaling a relational database is one of the most demanding challenges in system design. As applications grow from thousands to millions of active users, the database ceases to be a simple storage engine and becomes the primary bottleneck of the entire system architecture. In this technical guide, we explore the architectural progression of scaling MySQL—beginning with replication topologies, stepping through the complexities and operational hazards of manual database sharding (including proxy middleware like Vitess), and evaluating NewSQL alternatives, specifically the distributed architecture of TiDB. ...