Every six months a new architecture pattern shows up that promises to solve every problem. Most of the time the actual problem is simpler: the team needs the system to run, to be observable, and to be fixable at 3 AM.
The questions we ask first
Before we draw a single box on a diagram, we ask:
- What is the realistic peak load, not the marketing peak?
- Who is going to operate this in year two?
- How are we going to roll back if the next release is bad?
A workload that answers those questions well rarely needs anything exotic. A small EC2 fleet, a managed database, and a CDN can carry surprisingly large traffic if the application is built carefully.
When the hype matches the workload
There are cases where the new pattern is the right answer. Spiky workloads benefit from serverless. Massive parallelism benefits from queues and workers. The point is not to avoid modern patterns. The point is to choose based on the workload, not the conference talk.