Let me tell you a story about a system that had:
14 microservices
Kubernetes
message queues
observability dashboards
distributed tracing
CI/CD pipelines for each service
It looked beautiful.
It also did one simple thing.
Once a day.
At midnight.
The Problem
The system’s job was simple:
Pull data from an API
Process it
Store the results in a database
That’s it.
Yet somehow the architecture diagram looked like this:
API → Ingestion Service → Queue → Processing Service → Queue → Worker → Database
All running on Kubernetes.
With autoscaling.
For a job that ran once every 24 hours.
The Moment of Realization
During a debugging session someone asked:
“Why does this need three services?”
Silence.
Then someone said the sentence that changed everything:
“Could this just be… a cron job?”
The Architecture We Replaced It With
Before:
Kubernetes
├── ingestion-service
├── processing-service
├── worker-service
└── queue infrastructure
After:
cron → script → database
Lines of code dropped from ~4000 → ~300.
Infrastructure complexity dropped by about 90%.
Operational issues dropped to almost zero.
Why This Happens So Often
Developers love building distributed systems.
But many systems don’t actually need to be distributed.
What happens is usually this:
A simple system starts growing
Someone suggests microservices
The architecture becomes “future proof”
The future never actually arrives
Suddenly you have Kubernetes managing a workflow that could run inside a single Python script.
Microservices Are Great — When You Actually Need Them
Microservices solve real problems:
independent scaling
team autonomy
fault isolation
complex systems with many domains
But if your system:
runs once a day
processes a small dataset
is owned by one team
has a simple workflow
You probably don’t need microservices.
You might just need:
cron + script
The Hidden Cost of Over-Engineering
Every additional service adds:
deployment pipelines
monitoring dashboards
failure points
infrastructure cost
debugging complexity
When something breaks, you’re suddenly tracing requests across five services instead of reading one log file.
The Rule I Follow Now
Before building a distributed system, I ask one question:
Could this be solved by a cron job?
If the answer is yes…
Start there.
You can always add complexity later.
But removing it is much harder.
The Irony
The funny thing is that the simplest system often ends up being the most reliable one.
Because it has fewer things that can go wrong.
Sometimes the best architecture decision is simply not building more architecture.
Your Turn
Be honest.
Have you ever seen a system that looked like this?
Kubernetes + 10 services
…doing something that could have been solved with a cron job and 200 lines of code?
If yes, I want to hear that story 😄
Top comments (0)