Database

Prerequisite: This is the starting part of the series — no prior part is required. Later parts assume the concepts introduced here. Answer-first: A production-grade double-entry ledger enforces immutable, append-only transaction logs decoupled from balance state updates. By using fixed-size C-aligned memory structs or PostgreSQL check constraints and triggers, the schema guarantees strict debit-credit mathematical invariants, prevents hot-row lock contention, and eliminates double-spend risks in high-concurrency core banking architectures. Implementing this architecture enforces sub-50ms P99 latency guarantees, strict component isolation, and automated observability. ...

Prerequisite: Familiarity with the concepts introduced in Part 1 — Double Entry Ledger Schema. Review it first if the terminology in this part is unfamiliar. Answer-first: Distributed SQL engines preserve multi-region ACID serializability by combining Raft/Paxos consensus with bounded clock synchronization protocols such as Spanner TrueTime, CockroachDB HLC, or TiDB Percolator TSO. Selecting optimal commit-wait delays and timestamp allocation strategies minimizes two-phase commit overhead, achieving low transaction latencies across cross-region core banking nodes. Implementing this architecture enforces sub-50ms P99 latency guarantees, strict component isolation, and automated. ...

← Previous Chapter: Part 2 — Golang vs. PHP/Laravel | Series hub | Next Chapter: Part 4 — MariaDB vs. MySQL → Answer-first: For distributed write-heavy architectures (≥10,000 writes/s) on MySQL/InnoDB, Snowflake ID (64-bit) is optimal, eliminating the 50% secondary index multiplier tax while preserving B-tree locality. For PostgreSQL, client-generated keys, or coordinate-free distributed topologies, UUIDv7 (RFC 9562) delivers 98% sequential page packing without dedicated coordinator nodes, overcoming random UUIDv4 page thrashing and IOPS cliff failures. ...

Prerequisite: Familiarity with the concepts introduced in Part 2 — Event Driven Kafka. Review it first if the terminology in this part is unfamiliar. Answer-first: PayPay migrated its database layer from AWS Aurora MySQL to TiDB Distributed SQL to overcome vertical scaling limitations. TiDB’s Raft-based auto-sharding and horizontal compute/storage separation deliver linear scaling under billion-row transaction tables. Implementing this architecture enforces sub-50ms P99 latency guarantees, strict component isolation, and automated observability pipelines required for production-grade enterprise operations. ...

← Previous Chapter: Part 3 — Primary Key Showdown: UUIDv7 vs. Snowflake | Series Hub | Next Chapter: Part 5 — Sharded MySQL vs. TiDB NewSQL → Part 4: MariaDB vs. MySQL: Storage Engines & Thread Pool Showdown Answer-first: MariaDB is no longer a drop-in replacement for MySQL. MySQL 8.4/9.0 dominates Cloud-Native ecosystems (AWS Aurora) with InnoDB tuning, binary JSONB O(1) updates, and Vector AI. Conversely, MariaDB 11.x excels on Bare-Metal/Kubernetes via native ThreadPool (50k+ conns), Galera 4 zero-lag multi-master, and MyRocks LSM storage compressing disk by 70%. ...

Answer-first: Spatial indexing serves as a high-performance pre-filtering layer that prevents heavy routing engines from collapsing under load. By using Uber H3 hexagonal cells and Redis GEO to narrow down 10,000 active drivers to the 50 closest candidates in RAM (<2ms), systems reduce routing engine CPU overhead by up to 95%. Prerequisite: Before reading this part, review Part 2: Zero to Hero Environment Setup. Part 3: Spatial Indexing — Uber H3, PostGIS & Redis GEO Answer-first: Spatial indexing serves as a high-performance pre-filtering layer that prevents heavy routing engines from collapsing under load. By using Uber H3 hexagonal cells and Redis GEO to narrow down 10,000 active drivers to the 50 closest candidates in RAM (<2ms), systems reduce routing engine CPU overhead by up to 95%. ...

Answer-first: Enforcing ACID isolation levels in core banking prevents lost updates and dirty reads during high-concurrency transfers. Using PostgreSQL REPEATABLE READ or pessimistic row locking (SELECT FOR UPDATE) combined with Go connection pooling guarantees transactional integrity. Spanner and CockroachDB provide linearizable distributed ACID transactions across microservices using Paxos consensus and Hybrid Logical Clocks. Prerequisite: Part 2: CASA & Lending Domain Logic on transaction parameters. The Core Problem: Concurrency Answer-first: High-concurrency banking transfers risking race conditions and lost updates require strict database lock isolation to protect ledger state. ...

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. Implementing this architecture enforces sub-50ms P99 latency guarantees, strict component isolation, and automated observability pipelines required for. Chapter 4: Database Scale - The Rise of TiDB and NewSQL ← Series hub | ← Prev | Next → ...

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

← Series hub ← Prev • Next → Answer-first: 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. Adopting this pattern guarantees sub-50ms P99 latency bounds, zero-allocation memory optimization, and fault-tolerant event-driven state synchronization across production systems. Prerequisite: Phase 4: Technology Overview ...

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

Vitess vs GORM Sharding: MySQL Write Scaling in Go When an engineering organization scales beyond millions of active transactions, a monolithic relational database instance inevitably becomes the single biggest systemic bottleneck in the entire software architecture. While read traffic can be scaled horizontally almost indefinitely by attaching read replicas behind a load-balancing proxy like ProxySQL, write traffic hits an unyielding physical ceiling on a single MySQL Primary instance. Hardware upgrades (Vertical Scaling) provide temporary relief at an exponential cost curve, but cannot evade the physical laws of InnoDB buffer pool latch contention, redo log checkpointing stalls, and operating system fsync boundaries. ...

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