High-traffic SSR marketplace rescue
Pages failed intermittently, memory climbed until the server died — and restarting had become the coping strategy. This is how it was fixed.
- Engagement
- ~10 months, ongoing
- Role
- Production stabilization & frontend
- Scale
- High-traffic production marketplace
The problem
A large marketplace was failing in production — and only in production. Pages errored intermittently, memory climbed steadily until the server died, and no one could trace the cause. The team's workaround was restarting servers before they fell over.
A leak you can't reproduce locally doesn't show up in code review. It shows up at 2am, under real traffic, as a dead server.
What I did
Four pieces of work, in the order the risk demanded:
Diagnosed the memory leak
Profiled the running app under production-like traffic, compared heap snapshots over time, and isolated the code path that kept references alive. Then eliminated it — not patched around it.
Stabilized SSR under real traffic
Isolated render errors so one failing page can't take the whole process down, and cleaned up the failure modes that only appear when thousands of users hit the server at once.
Led a zero-downtime backend migration
Kept the frontend serving users while the backend was replaced underneath it — old and new running side by side, cut over incrementally, with a rollback path at every step.
Stayed on as the reliability owner
The engagement didn't end at the fix. I've owned production reliability on this app continuously since — new features ship without bringing the old instability back.
The outcome
The numbers that matter here are the ones that stopped happening:
- Memory usage flat — the emergency restarts stopped entirely.
- The intermittent page failures are gone, under the same real traffic that used to trigger them.
- The backend migration completed with zero downtime — users never noticed. The engagement is still running, ~10 months in; retention is the review.
Stack
No framework rewrite, no migration to something shinier — the fix was making the existing React/SSR stack behave under load. That's usually the job: the stack is fine, the production behavior isn't.
Does this sound like your app?
Every engagement here started the same way: an app already live, and a problem someone decided to stop living with. The audit is the low-risk way to start — read-only access, a written report, a prioritized fix list.