Good engineering decisions start with questions, not answers

Today I was thinking about latency, throughput, and system design.

Imagine two systems:
- System A has low latency but lower throughput
- System B has higher latency but higher throughput

At first, it feels like one should be better than the other.
But the more I learn, the more I realize the answer is usually it depends.

- For an exchange, throughput might become a critical constraint.
- For an HFT trading engine, a few milliseconds can determine whether an opportunity is captured or missed.
- For a messaging platform, the acceptable latency is very different from a trading system.

What I found most interesting wasn't comparing the numbers.
It was learning to ask better questions before making a decision:
- What kind of traffic will the system handle?
- What are the latency requirements?
- What happens during peak load?
- What problem are we actually trying to solve?

I'm starting to see that system design is mostly about understanding tradeoffs and constraints.
The numbers matter.
But the requirements matter first.