think in 3d
Traffic goes up, performance goes down, and the team reaches for one of two levers:
- horizontal scaling, adding more instances
- vertical scaling, buying bigger machines
Pause for a moment. Did you notice something missing? If not, you might be seeing in 2D.
Both levers treat the symptom. Both assume the application is already as fast as it can be. That assumption costs money, adds moving parts, and slows the team down.
There is a third dimension. Optimize the application. Think in 3D.
The third dimension
Application work often pays out far better than infrastructure work. An index can move a query by orders of magnitude. A cache can take most of the load off the database. Going from O(n²) to O(n log n) changes what is possible, not just what is fast.
Below that there is a whole layer most teams never touch:
- allocation patterns, arenas, bump allocators
- short-lived allocations and the GC pauses they cause
- serialization you didn’t need to do
- user-to-kernel copies and syscalls
- batched writes, zero-copy, aligned buffers
- pointer chasing that wrecks cache locality
- struct-of-arrays instead of array-of-structs, when the access pattern asks for it
These compound. A real improvement in code efficiency means far fewer servers, a smaller system, and room to grow into.
Why the third dimension is overlooked
It needs different skills:
- reading code for bottlenecks
- profiling before and after instead of guessing
- knowing when O(n) quietly became O(n²)
- the CPU, the memory hierarchy, the kernel
- how the components actually interact
Most teams either don’t have those skills or don’t reward them. Buying hardware is easier than fixing the code, and nobody gets in trouble for it. Invest in the skills instead.
Measure first, then optimize
Measure first. Profile the application and find the real bottlenecks:
- query performance
- allocation patterns
- CPU by function
- network I/O
Then fix the biggest one. A single good optimization usually beats several infrastructure changes.
Optimization compounds
Each improvement makes the next one easier. The code gets smaller, the system gets easier to reason about, and the costs stop surprising you.
When you think in 3D you stop scaling and start evolving.
Think in 3D.