In the Netflix series The Eternaut, there’s a moment that hits harder than it probably should.
After the electromagnetic pulse wipes out anything electronic, the world just… stops. Modern cars are useless, cities freeze, everything familiar suddenly becomes fragile.
Then Favalli finds an old car and tries to start it.
And it works.
“Lo viejo funciona, Juan.” ("the old works, Juan")
It’s a simple line, but it lands because it does something subtle: it pulls you back in time. Not just to “older technology,” but to a different world — ten, twenty, forty years ago — when things worked differently, when we were different, when the assumptions we made about the future were completely different.
That feeling shows up in a lot of stories. A forgotten machine that still works. An old tool that suddenly becomes essential. Not because it’s better, but because it was built for a different context — and somehow fits the present moment again.
⸻
Over the past few years, many microservices projects have turned into cautionary tales: systems that looked elegant on paper but became difficult to operate, evolve, or even understand.
In response, the idea of the “majestic monolith” has made a comeback.
And to be fair, there are majestic monoliths — just like there are beautifully restored classic cars. Carefully engineered, impressive, and sometimes exactly the right thing.
But also, very expensive and time-consuming and perhaps over-engineered, which is why that framing can be misleading.
Because most systems don’t need to be majestic. They need to be appropriate for their context, especially over the next one, two, or three years.
If you’re honest about those constraints, the question becomes less ideological and more practical: what kind of system will let you move, adapt, and operate with the least friction?
⸻
That’s where the idea of the “humble monolith” feels more grounded.
Not as a statement, but as a baseline.
A system with fewer moving parts, clearer boundaries, and behavior that is easier to reason about when something goes wrong. Something you can understand without needing to reconstruct a distributed narrative across multiple components.
Of course, monoliths can degrade into tightly coupled, hard-to-change systems. We’ve all seen that.
But so can distributed architectures — and often in ways that are harder to see and harder to fix.
⸻
Which points to the real issue.
The problem is not monolith vs microservices.
It’s rigidity.
We make architectural decisions early, based on assumptions about scale, growth, and future needs. And then those decisions get embedded into the system in ways that are difficult to reverse.
What started as a good fit becomes a constraint.
The system needs to evolve, but the architecture doesn’t.
⸻
Maybe that’s why moments like “lo viejo funciona” resonate so much.
Not because the past was better, but because it reminds us that different choices made sense under different conditions — and that those choices can still be valid when circumstances change.
In software, we rarely give ourselves that flexibility.
We pick a shape, and we’re stuck with it.
In the next post, I’ll explore a different approach: what it looks like when architecture becomes a runtime decision, and how the same system can take on different shapes — from a humble monolith to something more distributed — without rewriting everything.
Because sometimes, what matters isn’t choosing the right architecture upfront.
It’s being able to choose again when the world changes.
Thank you for having reached this far, I hope you find these ideas interesting. Now, have you worked on monoliths? how would you call it :-) , Or perhaps, contributed to projects using microservices or server-less architecture? I'm curious to hear from you in the comments!
Photo credits:
El Eternauta. César Troncoso As Favalli In El Eternauta. Cr. Marcos Ludevid / Netflix ©2025
Top comments (1)
the framing around rigidity is what makes this stick. it's not really monolith vs microservices, it's about how quickly you can change your mind when the context shifts. I've seen distributed systems that were technically impressive but effectively frozen because no one could reason about the whole anymore. the humble monolith label is useful precisely because it sets expectations correctly. it's not aspirational, it's honest about the tradeoffs. curious if the next post gets into modular monolith patterns, because I think that's where the real flexibility lives before you're forced to go distributed.