Database Sharding
Inspired by Design a Distributed Rate Limiter w/ a Ex-Meta Staff Engineer: System Design Breakdown
When to use sharding
- Write-heavy: Too much data for 1 instance (storage or write per second)
- Read-heavy: when read replicas or caching are not enough
Trade offs
- Global queries will be slower
- Complexity to operate and keep data consistent
Sharding methods
Hashing
Needs to be consistent (consistent hashing ).
How to choose a shard key
- high cardinality (lots of values to spread)
- even distribution so that every shard has the same amount of data
- when you query, you need only one shard
To avoid hot spots, perhaps you can shard a bit more granular, ie not just bye user id but by user id + post creation date
What not to do
Boolean is very low cardinality
Sharding by creation date where most people query the most recent year makes one shard hot, not evenly distributed
Range based sharding, like by user id might make hot shards, all users in one shard depending on how many
Directory based sharding
You can do directory based sharding where you stored somewhere in which shard the data is. Allows flexibility you can easily change in which shard something is ik case it's really hot, but it adds lots of latency as you need to look it up every time. Adds a single point of failure too.
You can do something hybrid where you manually store for hot keys in which shard they are stored, and use the normal hashing method for the rest.
Issues with sharding
Cross-shards requests
Some queries might need data across shards, and this could become really slow.
Remediation
You can cache expensive cross shard queries.
This is where de normalisation could have a use case, let the related data live in the same shard but multiple writes
Consistency
However, if you need to make atomic transactions across services or databases, then sharding makes it harder, but not impossible.
Splitting data across services breaks atomicity, creating distributed transaction challenges.
Distributed transactions
Easiest is to have all in one db that.
Resource
Youtube - Hello Interview – Sharding in System Design Interviews w Meta Staff Engineer
In this topic
- Distributed transactionsGrowing
2 phase commit and saga patterns are the most common ways to solve this. You can have a coordinator plan across services and commit all at once, but this is fragile if…
Sources
Referenced by
- Common System Design PatternsGrowing
Database Replication and read replicas. Something something geolocalisation. Postgres has extensions for this.
- How to choose a databaseEstablished
PostgreSQL. Strengths: transactions, joins, constraints, flexible queries. Weaknesses: horizontal scale/sharding complexity, not ideal for huge analytical scans. DynamoDB. Strengths: massive scale, predictable low-latency key access, operational simplicity. Weaknesses: access-pattern-driven modelling, limited relational…
- Message queuesEstablished
operations too long for a live server, get feedback to users quickly. reduce load on a live server. when you want the ability to scale differently for different tasks (ie retrievers need…