Brick by Brick vs Layer by Layer: What I Learned From 15 Years of Building Systems That Actually Survive

I've been thinking about bricks lately.

Not the software kind. The actual, physical, heavy-as-hell clay rectangles that humans have been stacking on top of each other for ten thousand years.

And I realized something uncomfortable: most of us in tech have been building systems completely backwards.

We're obsessed with layers. Clean abstractions. Neat separation of concerns. The beautiful, elegant onion architecture where everything sits perfectly in its designated tier.

But look at anything that actually survives — Roman aqueducts, medieval cathedrals, your grandmother's house in the countryside — and you won't find clean layers.

You'll find bricks.

The Layer Trap

I fell into it hard in 2018. Working on a data platform for a logistics company. We had the perfect layered architecture: ingestion layer, processing layer, storage layer, serving layer, API layer. Each one beautifully decoupled. Each one replaceable.

We spent six months designing the layers. Another four months arguing about where the boundaries should be.

When we finally shipped, it worked. For about three weeks.

Then the ingestion layer started leaking events. The processing layer couldn't keep up with the new data volume. The storage layer — which we'd designed for 100GB/day — was suddenly getting 400GB. And because everything was so cleanly layered, fixing one thing meant touching three others.

The system wasn't broken. It was just... fragile. Beautifully, academically, elegantly fragile.

What Bricks Taught Me

I spent a summer renovating an old stone house in the Algarve. Not because I wanted to — because the roof collapsed and I had no money to hire someone.

The walls were built in the 18th century. No layers. Just bricks and stone, stacked directly on top of each other. Each brick carrying the weight of what came above. Each brick part of the structure, not abstracted away from it.

Here's the thing about brick-by-brick construction: when one brick fails, the wall doesn't collapse. The bricks around it redistribute the load. The structure adapts.

Layer-by-layer construction? When one layer fails, everything above it falls.

The Real Difference

Let me be specific about what I mean, because I know someone's already typing "but microservices are bricks" in their head. No. Microservices are also layers, just distributed ones.

Brick-by-brick means:

• Each component is self-sufficient — it can function without the layers above or below
• Each component directly handles its own failures — no circuit breakers, no retry queues, no "resilience patterns"
• The system degrades gracefully — when something breaks, the rest keeps working, just slightly slower or with slightly less data
• You can understand the system by looking at one brick — you don't need to trace through five layers to understand what's happening

Layer-by-layer means:

• Each layer depends on what's below — the API layer is useless without the service layer, which is useless without the data layer
• Failure propagates upward — a slow database layer means a slow everything
• The system either works or it doesn't — there's no middle ground
• You need to understand all the layers to understand any single behavior

Where This Actually Matters

I'm not saying layers are always wrong. If you're building a simple CRUD app that serves 50 users, layer away. You'll be fine.

But if you're building something that needs to survive — survive data spikes, survive team changes, survive the next five years of business chaos — think about bricks.

Here's where I've seen brick-by-brick thinking make the difference:

Data pipelines. Instead of a clean ETL layered architecture, build each transformation as a standalone brick. Each one reads from the source, transforms, writes to the target. If one fails, the others keep running. You can add new bricks without touching existing ones.

APIs. Instead of a three-tier architecture, build each endpoint as a brick. Each one handles its own authentication, validation, business logic, and data access. Yes, there's duplication. Yes, it's "not DRY." But when one endpoint breaks, the other 47 keep working.

Documentation. Instead of a layered documentation system (architecture doc → API docs → code comments), write brick documentation. Each component explains itself. You can read one file and understand one thing completely.

What I Actually Do Now

I don't design systems anymore. Not in the traditional sense. I don't draw boxes and arrows. I don't create layers.

I ask one question: "If this component disappears tomorrow, does the rest of the system still work?"

If the answer is no, that component isn't a brick. It's a layer. And I need to rethink it.

This isn't about being anti-abstraction. Abstractions are useful. But they should be conveniences, not dependencies. You should be able to remove any abstraction and still have a working system. It might be uglier. It might be slower. But it should work.

The Hard Truth

Here's the insight that took me 15 years to learn:

Layers make systems easier to build. Bricks make systems easier to survive.

Most of us optimize for the first six months. We want to ship fast, look good, get promoted. Layers help with that.

But if you're building something that needs to outlast you — a platform, a product, a team — you need bricks.

The Roman aqueducts are still standing. The layered software I built in 2018 was rewritten in 2021.

I know which approach I'm betting on.

This isn't about being anti-architecture. It's about being pro-survival.

The Ermite Shinkofa