A performance pass across the whole backend
Everlyst got a full scalability audit and two waves of fixes: faster job progress, batched database writes, and queue processing that isolates a single bad listing instead of failing its neighbours. Nothing you can point at on screen, and that is the point.
Nothing was slow. That is worth saying up front, because this is the sort of work that is easy to dress up as a rescue. Everlyst is young and the catalogs on it are not yet large enough to strain anything. The problem with waiting for a system to feel slow is that by the time it does, the people it is failing are paying customers, and the fix has to happen under pressure.
So the whole backend went under audit instead, looking specifically for patterns that hold up fine at today’s size and degrade badly at ten or a hundred times it. Roughly eighteen findings were worth acting on. The ones that landed in this pass:
- Job progress used to re-count every item in a job on every poll. It now reads a single row of counters that each finished item updates atomically. A job with five thousand items costs the same to check on as a job with five.
- Database writes across listing sync, analytics import, review import, and rollups are now batched rather than issued one row at a time.
- The queue now processes messages in batches, with per-message error isolation, so one listing that Etsy rejects no longer takes its batch down with it.
- Sessions no longer write to storage on every single request.
- Several missing indexes were added, and one expensive query that dug into stored JSON on every row was replaced with a real column.
Editing feels the same today. It should still feel the same when your catalog is ten times the size.