Everything works… until it doesn’t.

There once was a small blue submarine.

It wasn’t built to be fast or impressive. It didn’t carry weapons or advanced gadgets. Its only real purpose was to go deep, and come back.

The engineers who designed it knew something important:
The deeper it went, the less forgiving the environment would be.

So they made choices that didn’t look exciting at first:
• Fewer moving parts
• Clear separation between critical systems
• Redundancy where failure wasn’t an option
• And no single component on which everything depended

In shallow water, none of this really mattered.
The submarine could have been simpler. Cheaper. Faster to build.

But that’s not where it was meant to operate.

As it descended, pressure increased. Small weaknesses that would never show up on the surface suddenly mattered. Bolts, seals, connections, everything was tested at once.

And the submarine stayed calm.

Because it had been designed for that moment.

Years later, I watched a production system do the opposite.

It worked beautifully at first. Traffic was modest. The architecture was clean. Everyone was happy.

Then usage grew.

What had been ~5,000 daily active users became 12,000. Then 18,000.

At first, nothing broke. Things just slowed down a little.
Enough to notice. Not enough to panic.

Until one day, under real load, the system went deep.

A critical internal call slowed down. Other parts of the system waited on it. Retries multiplied the problem. Resources were filled up.

The platform didn’t crash; it just stopped behaving predictably.

Some features worked. Others didn’t.
The system was technically “up”, but practically unusable.

The architecture wasn’t wrong.
It just hadn’t been built for pressure.

Too many responsibilities live in one place.
Too many assumptions had been made while everything was calm.

The post-mortem sounded familiar.
• Pressure isn’t an edge case.
• Redundancy without clear ownership doesn’t help.
• Systems survive depth only when they’re designed for it.

The fixes were simple, not flashy:
• Clearer boundaries
• Fewer shared dependencies
• Realistic testing
• Shared responsibility for critical paths

After that, the system didn’t just survive growth; it became boring.

And boring, in production, is success.

That’s why the small blue submarine works.

And that way of thinking, about pressure, systems, and design, is something I care deeply about at iForce Connect.