Database

Prerequisite: Part 4 of the System Design Masterclass. Read Part 3: Caching Strategies to understand the cache layer before examining storage. Answer-first: Database sharding distributes data horizontally across independent partitions (shards) based on a shard key, reducing write contention and enabling linear storage growth. Choosing the wrong shard key leads to hot spots that can be worse than no sharding at all. Vertical vs Horizontal Scaling — When to Switch? Answer-first: Vertical scaling (scale-up) increases resources on a single server — simple but has a hard physical ceiling and non-linear cost growth. Horizontal scaling (scale-out) adds more servers — no theoretical ceiling, linear cost, but significantly higher operational complexity. ...

← Previous | Series hub Chapter 9: Scaling the Final Database Bottleneck When your application reaches tens of millions of users, the Database becomes the ultimate bottleneck. CPU maxes out at 100%, RAM depletes, and queries take seconds instead of milliseconds. This is the stage where you must deploy distributed database strategies. 1. Read/Write Splitting Answer-first: Because 80% of traffic is Read-only, separate your DB into a Write Master and Read Slaves. Use GORM’s dbresolver plugin to route queries automatically without altering business logic. ...

← Previous | Series hub | Next → Chapter 5: Unlocking Database Performance via Connection Pooling If your Golang system processes business logic blazingly fast but chokes at the Database layer, 90% of the time, it is due to an incorrectly configured *sql.DB. 1. Understanding *sql.DB Answer-first: In Golang, sql.Open() does NOT create a direct database connection. It instantiates a thread-safe Connection Pool manager. You must initialize the db variable only once during app startup. ...

Part 6: Migration Playbook – Consolidating Microservices into a Monolith Breaking a Monolith into multiple Microservices is often referred to as the Strangler Fig Pattern. The process of consolidating distributed Microservices back into a central Monolith system follows the opposite direction: the Reverse Strangler Fig Pattern. Although merging application code might seem simple, the highest risks of this process lie in the Database and the Organization. Below is a step-by-step practical Playbook to consolidate architecture safely (zero-downtime). ...