the rewrite you probably don’t need
When a service gets slow, "rewrite it" is the reflex. It is also usually the most expensive way to fix a problem you have not measured yet.
When a backend gets slow or scary, the instinct is to rewrite it. A clean slate feels like the honest fix. It is also the most expensive, highest-risk option, and teams reach for it before anyone has measured where the time actually goes.
Slowness is almost never spread evenly. It concentrates - a handful of endpoints, a few N+1 queries, a missing index, one hot path that dominates traffic. Instrument the thing first and the real cost shows up instead of being guessed at. More often than not, a week of targeted work buys back what everyone assumed needed a quarter-long rewrite.
before you rewrite, measure
- add traces to the hot endpoints so the real cost is visible, not assumed
- find the queries that account for the tail latency - usually a small list
- fix those, add caching where reads dominate, and re-measure
Sometimes a rewrite really is the answer. But you should earn that conclusion with data, not reach for it out of discomfort. A legible, well-instrumented service you already run is worth more than a clean one you have not built yet.
have a system this describes?
If any of the above sounds like something you run, tell us about it. We answer every message ourselves.