Database Sharding
Related service Custom software · everything else
DEFINITION
Splitting one big table/DB across many machines by a shard key so it scales past one server. Powerful but adds real complexity — we avoid it until we must.
- Docker→
We package an app with its dependencies into an image, which runs as a container — identical on your laptop and in production. "Works on my machine" stops being an excuse.
- CI/CD→
Continuous Integration / Delivery: every commit is automatically built, tested and (optionally) deployed. This pipeline lets us ship safely many times a day, without manual mistakes.
- Blue-Green Deployment→
We run two identical environments: blue is live, green is the new version. Once green is verified we flip traffic to it; on trouble we flip back instantly. Zero-downtime releases with instant rollback.
- Horizontal Scaling→
We add more machines/instances (scale out) instead of one bigger box (vertical, scale up). For stateless services this wins: cheaper, more elastic, no ceiling. State goes to a separate store.
- Load Balancer→
Distributes incoming traffic across multiple instances — the front door that gives you redundancy and smooth scaling. Health checks remove dead instances, so one failure stays invisible to users.
- Distributed Tracing→
We follow one request across every service using a trace ID (e.g. OpenTelemetry). In a microservices system this is how we pinpoint which service slowed down or failed — no guessing.