Three seconds to load the moderation queue, and the compliance team kept it open all day.
It was a KYC review list: pending applications, one row each, with a status telling the moderator what to do next. That status was not stored anywhere. It got computed: provider verification result, uploaded documents, AML flags, plus a precedence rule deciding which of them wins. For every page the endpoint fetched the applications, then their checks, then ran the same precedence logic the detail view used.
I killed the N+1 first. That got it under two seconds and no further. The rest of the time was Python resolving precedence over thousands of check rows, on every single request, to produce an answer that almost never changed between two refreshes.
The real fix was to stop deriving status on read. One function owns the precedence rule, it runs when a check lands, and it writes the resolved status to a column. The list endpoint became a filtered, indexed read. Two hundred milliseconds.
The part I didn't plan for: moderators could finally sort and filter by status. While the status only existed inside a request, that was impossible.
So now, when a list endpoint shows a status, my first question is not how to make the query faster. I ask whether a human will ever filter or sort by that value. If the answer is yes, it's a column with a single writer rather than a computation, and the computation becomes a backfill job instead of a hot path.
Probably some derived field in your system is quietly load-bearing on the read path right now...