Why Full Serverless Can Be a Trap

The original post surfaced on my X feed and I bookmarked it for a while. I felt curious and wanted to know why these problems occur with serverless architecture, so I did a deep-dive with Gemini today and this post is about what I learned.

Keisuke Nishitani @Keisuke69 · 5 Aug 2025 · link 🔗

サーバーレスで作ってしまったシステムの技術負債化三大あるある

• スケールはするがコストで爆死
• DynamoDBが辛い。とにかく辛い
• ログが行方不明。そして課金爆発

他にもいっぱいあって3個じゃ足りなかった
初期設計で詰むと、Lambdaはマジで不動産みたいになる

The three most common pitfalls of technical debt in serverless systems

• It scales, but the costs are catastrophic
• DynamoDB is tough. Just really tough
• Logs go missing. And billing explodes

There are tons more, and three isn’t enough
If the initial design fails, Lambda seriously turns into real estate

I feel fortunate that there are people posting these warning signs and that LLMs are widely accessible that I can dig into why the case with an LLM and learn the lessons from others even-though I myself have yet to work on severless architecure.

“It scales, but the costs are catastrophic”

The problem here is the system scales perfectly, but your bank account doesn't. Whether its legitimate traffic or something buggy with the calling code, you’ll be paying for every single call and the duration of those lambda calls. A lesson for me here is that, in a serverless context, the quality of the code we deploy directly impacts business bottomline. Inefficient code or chatty functions will cost more money than necessary and conversely, well-designed functions can reduce cost and save money.

Lesson: Every line of code in the cloud could cost you money, so understand the workload and access pattern of your service, then decide whether a serverless, or any technology is designed to handle such workload.

Question to Ask: Is the traffic is spiky, unpredictable, infrequent, or is it steady, high-traffic?

“DynamoDB is rough. Just really rough”

My interpretation of this one has to do with failing to thoroughly examine limitation imposed on the system when making decision about what technology to adopt, especially when its as foundational as database types and their designs. These are the so called One-Way door decisions that are nearly impossible or incredibly costly to reverse.

Lesson: Scrutinize foundational “one-way door” decisions.

Question to Ask: What are the limitations or constraints imposed on our system if we adopted this technology/design?

“Logs go missing. And billing explodes”

I didn’t quite understand the reason behind this, but according to Gemini, the trap here seems to be that in a serverless architecure, if 500 requests happen at once, then you get 500 separate, scattered log files. Trying to trace one user’s journey as they are passed between different serverless fx is very difficult. In order to solve this, you have to use another service (like AWS CloudWatch) to gather all the logs into one place, which itself costs money. So you pay to ingest the logs, and you pay to store them. If your functions are very "chatty" and log a lot of information, this logging service can become one of the most expensive parts of your entire application. So it’s a double-whammy: it’s not only hard to find the error, but you’re also paying more money to manage the logs.

Lesson: Log management in serverless architecure is not only different but potentially much more costly and more difficult to understand compared to a simple, traditional server.

Question to Ask: Is the cost and difficulty introduced in tracking errors and debugging in such an serverless environment a worthy trade-off?

So the ultimate lesson for me is as the author said: “Lambda is like real estate”. The decisions you make at the very beginning, the foundation, the plumbing, the electrical, are incredibly difficult and expensive to change later. In the same way, if you go “full serverless”, like choosing DynamoDB and structuring your data for it, becomes your foundation. If you get that foundation wrong, it’s going to be very painful and expensive to migrate away from.

Takeaway Questions

• What is the workload of your application and is this technology designed to handle such access pattern?
• Is this a foundational decision and is this also an “one-way door” kind of decision?
• What are cost impact of this design and how does it affect the monthly bill if scaled?

I feel fortunate that there are people posting these warning signs and that LLMs are widely accessible that I can dig into why the case with an LLM and learn the lessons from others even-though I myself have yet to work on severless architecure.