How "Stateless Purism" Broke Our System

One Day, Someone Said “Let’s Use Airflow”

An infrastructure-focused engineer joined our project mid-way through.

His proposal sounded simple:

• Orchestrate everything with Airflow
• Turn each subsystem into a microservice
• Make everything a stateless REST API

On the surface? Perfectly reasonable. Even “modern.”

Nobody objected at this point.

When “Ideal Design” Destroys the Real System

Here’s where things went wrong.

He started demanding changes to the existing system based on his “ideal architecture”:

• Convert all inter-subsystem communication to APIs
• Eliminate any process that holds state
• Control everything from Airflow

The result?

👉 All responsibility collapsed into Airflow.

Airflow Became a Monster

Airflow is supposed to be a “workflow management tool.” Nothing more.

But it turned into this:

• Data consistency checks → Airflow
• State management → Airflow
• Retry logic → Airflow
• Parts of the business logic → Airflow

And naturally:

👉 DAGs exploded in size 👉 Dependencies became chaotic 👉 Debugging became impossible 👉 Any change broke everything

Complete deadlock.

What Was the Original Design?

The original architecture looked like this:

• Each subsystem had clearly separated responsibilities
• Each system held the state it needed internally
• Systems were loosely coupled, encapsulated at meaningful boundaries

In other words:

👉 A design where state was held at the right granularity.

Then someone came along and said:

👉 “Make it stateless.”

And broke everything.

Stateless Is Not a Silver Bullet

This is the core lesson.

Stateless is a good design principle, but if you ignore:

👉 At what granularity should state be held? 👉 What should be treated as a single responsibility?

…then it’s just ideology being forced onto the system.

The Real Failure

The problem wasn’t technology.

👉 The encapsulation design was broken.

Specifically:

• State that should have lived inside subsystems was externalized
• APIs were sliced too thin (granularity was too fine)
• Airflow ended up becoming the state management layer

In other words:

👉 They thought they were distributing — but they were actually centralizing.

A Common Misconception

Microservices = stateless.

This is half right, half wrong.

The correct framing:

👉 Individual services can and should hold their own state. 👉 The interfaces between services should be simple.

Lessons Learned

The takeaway is simple:

• Don’t obsess over making everything stateless
• Airflow is for orchestration, not processing
• Get the encapsulation granularity wrong and everything collapses

And the most important lesson:

👉 Infrastructure knowledge ≠ system design skill.

The Bottom Line

Even “correct” technology breaks things when applied incorrectly.

Worse — it can destroy something that was already working.

The most important thing in design is:

👉 Not ideology — but responsibility and granularity.

A Personal Regret

The biggest failure here was:

👉 Not stopping it sooner.

A design that sounds “theoretically correct” is hard to push back on.

But asking:

👉 “Will this actually work in practice?”

…is always worth doing.

This pattern — where idealism breaks real systems — is incredibly common. I hope sharing this helps someone avoid the same mistake.