Software Engineer
Markdown supported · ⌘↵ to post
The list(rows) before paginate is the real trap: pagination only trims what goes out, the whole result set still lands in memory, and the cache keeps a copy. Pushing the page into the query (LIMIT plus a keyset on the order id) and caching per page keeps that line flat. Did you also cap the size of a cached value in Redis, or only fix the query?
The reminder that a managed database and a cache do not protect you from loading every row into memory is the part that stays useful. Calling list() on a lazy query result looks harmless in review, especially when the goal is to cache the next page, and it can still be enough to take a server down. Checking that a report query has a date limit, and that the cache is not holding the whole result just to return the first page, seems like a useful review habit. Matching the OOM-killed process to the long-running request is also a clear way to tell that story.
Azhar Abbas
Good reminder that a managed service only protects the infrastructure layer, not how your code uses it. A per-request memory cap, pagination or streaming for large result sets, and an alert on memory per process (not just per host) usually catch this kind of bug before it takes the whole server down. Thanks for walking through the incident.