---
title: "Discussion on \"Managed Services Won't Save You From Your Own Code\" | Hashnode"
description: "Discussion on \"Managed Services Won't Save You From Your Own Code\". One request, all the memory on the server, and a line of code that worked fine for years\nEarly one morning I got an alert that one of our production servers had become unhealthy.\nOn paper we had done"
url: "https://hashnode.com/posts/managed-services-won-t-save-you-from-your-own-code/6af750b29f0a9eb118bc7fd0"
---

[Feed](https://hashnode.com/feed) /

Discussion

# [Managed Services Won't Save You From Your Own Code](https://blog.mostafade.com/managed-services-won-t-save-you-from-your-own-code?utm_source=hashnode&utm_medium=feed)

One request, all the memory on the server, and a line of code that worked fine for years Early one morning I got an alert that one of our production servers had become unhealthy. On paper we had done

1d ago · 8 min read · blog.mostafade.com  
Read the article

## Written by

[Mostafa-DE](https://hashnode.com/@mostafade)

@mostafade

  
[View profile](https://hashnode.com/@mostafade)

Software Engineer

## Responses 3

Markdown supported · ⌘↵ to post

[Azhar Abbas](https://hashnode.com/@azharabbas)

[1d ago](https://hashnode.com/posts/managed-services-won-t-save-you-from-your-own-code/6af750b29f0a9eb118bc7fd0/comment/6af80fdbd39700cb746c41bf)

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.

[Vic Moreno](https://hashnode.com/@itsvicmoreno)

[4h ago](https://hashnode.com/posts/managed-services-won-t-save-you-from-your-own-code/6af750b29f0a9eb118bc7fd0/comment/6af979e4fa6bf7041d0d0c75)

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?

[QRiQRa Team](https://hashnode.com/@qriqra)

[1d ago](https://hashnode.com/posts/managed-services-won-t-save-you-from-your-own-code/6af750b29f0a9eb118bc7fd0/comment/6af84bd6e96debdd045ffd89)

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.