Most performance problems I’ve been called in to fix weren’t really performance problems. They were data-modeling decisions made early, under time pressure, that only revealed their cost once traffic showed up. Scale isn’t something you add later - it’s something you either designed for or didn’t.
Model the domain, then the access patterns
I start with two questions, in this order:
- What are the real entities and relationships in this domain?
- How will they actually be read and written?
The second question is the one people skip. A schema that’s beautiful on paper but fights every query you run is a slow schema. I design tables and indexes around how the data will be used, not just how it can be normalized.
SQL or NoSQL is a fit question, not a fashion one
I’ve built on both, and neither is a default. Relational stores earn their place when relationships and consistency matter - which is more often than the hype suggests. Document and key-value stores earn theirs when access patterns are simple, well-known, and enormous. The mistake is choosing by trend instead of by shape of the problem.
Indexes, and the cost of every one
An index makes reads faster and writes slower, and it costs memory. That trade-off is fine - as long as it’s deliberate. I add indexes to serve specific query patterns, not speculatively, and I remove ones that stopped earning their keep. An unused index is pure overhead pretending to be safety.
Let boundaries do the scaling
When a system needs to grow, the clean seams are what save you: a well-defined service boundary, a queue between producers and consumers, a cache with an honest invalidation story. None of these are exotic. They’re the difference between scaling by adding capacity and scaling by rewriting under duress.
The quiet goal
The best-scaling systems are boring. They stay fast without heroics because the hard thinking happened early, at the data layer, where it’s cheap. That’s where I’d rather spend the effort - so nobody has to spend it at 3 a.m. later.