TiDB

Series Navigation: This is Part 2 of the Core Banking Systems Architecture Masterclass. ← Previous: Part 1 — Double-Entry Ledger Schema | Master Curriculum Hub | Next: Part 3 — Event Sourcing & CQRS → | Pillar Hub: Go Microservices Guide Distributed SQL ACID Latency: TiDB, CockroachDB & Spanner Answer-first: Distributed SQL platforms achieve horizontal write scalability and multi-region fault tolerance by pairing Multi-Raft consensus with bounded distributed clock synchronization. However, speed-of-light propagation across geographic regions imposes unavoidable 15ms to 45ms round-trip consensus latencies. Core banking architectures mitigate these penalties through locality-aware range leasing, pipelined Percolator two-phase commits, and stale follower reads for high-throughput balance inquiries. ...

Previous Chapter: Part 2 — Event-Driven Architecture & Kafka at Scale | Series Hub | Next Chapter: Part 4 — SRE Practices & Chaos Engineering Answer-first: Facing hard single-writer throughput limits on Amazon Aurora MySQL during promotional peaks, PayPay migrated its core financial ledger to TiDB Distributed SQL. By leveraging Multi-Raft consensus across TiKV storage nodes, AUTO_RANDOM primary keys to eliminate hot-region bottlenecks, and Percolator-based distributed transactions, TiDB delivers linear write scaling, zero-downtime online DDLs, and sub-15ms P99 ledger settlement. ...

Previous Chapter: Chapter 3 — Traffic Shield & Peak Shaving | Series Hub | Next Chapter: Chapter 5 — Full-Stack Observability Answer-first: Shopee eliminated relational database bottlenecks by migrating mission-critical checkout clusters from sharded MySQL to TiDB NewSQL distributed storage. Decoupling stateless SQL compute from Multi-Raft consensus storage across 96MB TiKV regions enables elastic scaling, automated split-merge rebalancing, and Google Percolator distributed transactions, guaranteeing sub-twenty-millisecond p99 write latency and zero data loss across availability zones. ...

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

Core Banking Systems Architecture Masterclass Guide Answer-first: Modern cloud-native core banking transitions from batch-driven mainframes to composable distributed platforms: immutable double-entry ledgers enforcing mathematical zero-drift balance invariants, multi-region Distributed SQL guaranteeing serializable ACID transactions, event-sourced CQRS projections, orchestrated compensation Sagas, zero-allocation ISO 20022 streaming, and FAPI 2.0 security. This architecture eliminates end-of-day batch freezes, delivering sub-25ms P99 latency across active-active deployments. Prerequisite: Practical familiarity with distributed systems fundamentals, relational transaction isolation levels (ACID), event-driven microservice patterns, and enterprise networking (mTLS, TCP/IP, gRPC). For foundational context, explore our Banking Microservices Architecture and Go Microservices Guide. ...

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

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. For core microservices foundations, explore our Go Microservices Production Patterns. 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. ...