Every Scaling Decision Creates the Next Challenge
The decisions that got you here won't get you to the next stage. Adding a cache solves the speed problem and introduces a consistency problem. Distributing across nodes solves the capacity problem and introduces a coordination problem. That's not failure. That's what growth looks like.
Five patterns describe how data architectures respond to growth. Locate the one that sounds like your situation. The two paths below pick up from where your architecture is today.
Single System
One database handles everything. Caching absorbs read load.
Cache-centric pathSpecialized Persistence
Multiple systems, each optimized for a different workload.
Cache-centric pathDistributed by Default
Everything is a cluster. Coordination becomes the bottleneck.
Managed Consistency
Consistency orchestrated across distributed systems.
Distributed SQL pathAcceleration Database
Consistency built into the data layer through schema-driven placement.
Distributed SQL pathWhere is your architecture right now?
Two paths, two different starting points. Pick the one that sounds like your situation. Each leads to hands-on tutorials with working code you can run on your laptop.
My database works, but it is not fast enough
Your architecture did its job getting you here. Now response times are climbing, and adding read replicas or bigger hardware has stopped helping. You need a caching layer that understands your data model and keeps itself consistent without extra application code.
- An existing relational database under read pressure
- Hot data that changes and must stay consistent
- Application code you would rather not rewrite
I need distributed ACID transactions at scale
Your workload has outgrown a single node. You need a system of record that distributes data across a cluster, supports SQL and key-value access, and guarantees ACID transactions across partitions without giving up the consistency your application depends on.
- A distributed primary data store, not just a cache
- Multi-table ACID transactions across partitions
- SQL plus programmatic APIs on the same data
Starting from scratch? Compare both approaches.
No legacy constraints, no existing architecture to work around. Your choice depends on the workload you are building for.
Cache-centric acceleration
Best when you have a database that needs to be faster.
- Sits in front of an existing database
- Speeds up reads with in-memory caching
- Keeps cache and database in sync automatically
- Minimal application changes required
Distributed SQL
Best when you need a primary data store that scales horizontally with ACID guarantees.
- Replaces or supplements your primary data store
- Distributes data across a cluster with ACID guarantees
- SQL, key-value, and compute APIs on the same data
- Designed for workloads that outgrow a single node
Ready to start building?
Jump straight into a tutorial, solve a specific problem with a guide, or browse the full learning path catalog.