arnau díaz

think in 3d

2022 / 01 / 12  ·  time  ·  2 min

Every time I have watched traffic go up and performance go down, the team reached 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 treat the symptom. Both assume the application is already as fast as it can be, and I have almost never found that to be true. The assumption costs money, adds moving parts, and slows everyone down.

So I try to remember the third dimension. Optimize the application. Think in 3D.

The third dimension

In my experience application work pays out far better than infrastructure work. An index moved a query by orders of magnitude for me. A cache took most of the load off a database. Going from O(n²) to O(n log n) changed what was possible, not just what was fast.

Under that there is a layer I did not know existed for years:

  • 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 asks for skills I had to go and learn:

  • 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 I have been on either did not have those skills or did not reward them. Buying hardware is easier than fixing code, and nobody gets in trouble for it. I would rather spend the time on the skills.

Measure first, then optimize

I measure first. I profile and look for the real bottlenecks:

  • query performance
  • allocation patterns
  • CPU by function
  • network I/O

Then I fix the biggest one. One good optimization has usually beaten several infrastructure changes for me.

Optimization compounds

Each improvement made the next one easier. The code got smaller, the system got easier to hold in my head, and the bill stopped surprising me.

That is the part I did not expect: thinking in 3D stopped feeling like scaling and started feeling like gardening.

Think in 3D.