Sharding hard
When using 'App-Level Sharding' (where the app handles all routing) instead of a 'Proxy-based' approach, what is the 'Connection Explosion' problem?
- A The database engine will run out of memory due to the massive number of active SQL queries being executed simultaneously.
- B Each application instance must maintain a persistent TCP connection pool to *every single database shard* (N Apps * M Shards), which can overwhelm the database's available file descriptors.
- C The application will generate so much random network traffic that the datacenter switches will begin dropping packets.
- D Every database write will be duplicated to every single shard, leading to a exponential increase in storage costs.
Answer: B. Each application instance must maintain a persistent TCP connection pool to *every single database shard* (N Apps * M Shards), which can overwhelm the database's available file descriptors.
A standard database (like MySQL or Postgres) consumes several Megabytes of RAM for every open connection. If you have 500 microservice pods and 100 database shards, that is 50,000 idle connections just sitting there! This 'Connection Tax' is many physical servers' worth of RAM wasted on keeping TCP sockets open. This is why tools like Vitess or PgBouncer are critical; they 'multiplex' these thousands of app connections into a much smaller, high-speed pool of connections used by the actual database nodes.
One system design question a day, with spaced repetition so the ones you miss come back.
Get the appRelated questions
- In an E-Commerce platform, why might you choose to shard the `Orders` table by `user_id` rather than the more obvious `order_id`?
- In the context of database scaling, what is the fundamental difference between 'Vertical Partitioning' and 'Horizontal Partitioning' (Sharding)?
- If Shard A fails in a large cluster, and its incoming traffic is automatically re-routed to Shard B, what is the risk of a 'Cascading Failure'?
- In a standard 'Modulo Sharding' setup (`key % N`), what is the primary consequence of adding a new server to the cluster (increasing N from 10 to 11)?
- From an engineering perspective, when should you choose 'Vertical Scaling' (a bigger server) over 'Horizontal Scaling' (Sharding)?
- Which sharding strategy is mathematically optimized for efficient 'Range Scans' (e.g., retrieving all records created between January and March)?