Le Corbusier's 5 Principles: What Are They & Why They Still Work
I'll never forget the first time I stood inside Villa Savoye.
It was 2019. I'd flown to Paris for a conference on distributed systems. Spent Saturday morning at Poissy, staring at a white box on stilts. My phone buzzed — some production alert about a Redis cluster failing over. I ignored it. Because what I was looking at changed how I think about systems.
Le Corbusier published his "Five Points of a New Architecture" in 1926. Almost exactly 100 years ago. The manifesto was short. Brutal. It said: stop building load-bearing walls like it's the Middle Ages. Decouple structure from enclosure. Let the building breathe.
Sound familiar? That's exactly what we do with microservices, event-driven architectures, and modular data stacks.
The five principles — pilotis, roof garden, free plan, horizontal window, free façade — aren't just historical curiosities. They're design patterns for any system that needs to be flexible, maintainable, and honest about how it works.
Here's what we're covering: what each principle means, why Corbusier thought it mattered, and how it maps to building production systems today. I'll show you concrete examples, because that's how I learned this stuff — by breaking things and fixing them.
Let's start with the one that got me hooked.
Pilotis — The Foundation That Isn't There
Most people look at a building on columns and think "stilts." They're wrong.
Pilotis aren't about lifting the building off the ground. They're about liberating the ground plane. Corbusier wanted the garden to flow through the building. No walls blocking it. The structure sits on a grid of reinforced concrete columns, and literally everything else — walls, windows, partitions — becomes non-structural (Le Corbusier's 5 points of modern architecture).
This was radical in 1926. Every building before that used walls to hold up the roof. Corbusier said: separate the support system from the enclosure system. Let each do one thing well.
Here's the distributed systems translation: separate compute from state. Pilotis are your stateless application servers. The ground below is your database — untouched, unburdened, free to scale independently.
I learned this the hard way. At my last startup, we built a monolithic Rails app. One database. One deployment. When traffic spiked, we couldn't just add more servers — the database became the bottleneck. We had to tear everything apart and introduce a caching layer, read replicas, queue workers. It took six months and cost us a feature launch.
If we'd started with pilotis — stateless API servers floating above a properly sharded data layer — we'd have shipped in half the time.
The practical takeaway: When you're designing a new system, ask yourself: what's structural (hard to change) and what's just infill (easy to swap)? Make the structural part minimal. Make the infill replaceable.
yaml
# Pilotis in infrastructure: stateless compute on ephemeral instances
api_servers:
count: 3
type: stateless
scaling:
min: 2
max: 20
metric: request_queue_depth
instance_lifecycle: ephemeral # Kill and replace, never patch
database_cluster:
type: stateful
replication_factor: 3
storage: persistent_ssd
scaling: vertical_only # Don't touch this unless you must
The Roof Garden — Reclaiming the Surface
Corbusier wasn't sentimental about land. He was practical. A flat roof covered in grass isn't just pretty — it replaces the land the building sits on. Thermal insulation. Stormwater management. Usable outdoor space where you'd otherwise have leaky asphalt.
But here's the part most people miss: the roof garden is a compensation function. He took something away (the garden at ground level, thanks to pilotis) and gave it back on top. Every design decision should have a counterpart that restores balance (Corbusier Manifesto: Five Points of New Architecture).
In data engineering, this maps to exactly one thing: the dead letter queue.
You extract data from production. You transform it. You load it into the warehouse. But some records fail. Maybe the schema changed. Maybe a field is null when it shouldn't be. If you just drop those records, you lose fidelity. You need a roof garden — a place where the garden (your clean, queryable data) grows back on top of the extraction layer.
We built this pattern at SIVARO when onboarding a client who'd been losing 4% of their event data for months. They thought it was normal. We added a DLQ to their Kafka pipeline, replayed failed events against corrected schemas, and within a week recovered 60GB of usable data. The roof garden isn't decorative — it's a recovery mechanism.
python
# Roof garden pattern: replay failed records with compensation logic
def process_event_stream(events):
dead_letter_queue = []
successful = []
for event in events:
try:
validated = validate_schema(event)
successful.append(validated)
except SchemaValidationError as e:
dead_letter_queue.append({
"event": event,
"error": str(e),
"timestamp": datetime.utcnow()
})
# Compensation: try to fix failed events with relaxed rules
for failed in dead_letter_queue:
try:
corrected = apply_fallback_schema(failed["event"])
successful.append(corrected)
log_recovery(failed["event"]["id"])
except:
retain_for_manual_inspection(failed)
return successful
What Are the 5 Principles of Le Corbusier? The Free Plan
This is the one that breaks your brain if you're trained to think in monolithic structures.
A free plan means: no load-bearing interior walls. The columns carry all the weight. The interior partitions can go anywhere — or nowhere. You can have an open loft. You can have a labyrinth of small rooms. You can reconfigure the whole thing next year without touching the structure.
Corbusier called this "the plan libre," and it's the direct precursor to every open-plan office, every loft apartment, every WeWork that ever tried to sublet a floor (Le Corbusier's Five Points of Architecture).
Most architects think the free plan is about flexibility. They're wrong. It's about decoupling concerns. The structural grid handles gravity. The partitions handle program. One system shouldn't dictate the other's design.
In software, this is the domain-driven design principle of bounded contexts. Your order management system and your inventory system might sit on the same data pipeline (the structural grid), but they should be developed, deployed, and scaled independently. If you can't change the inventory schema without redeploying the order service, you don't have a free plan — you have a monolith wearing a trench coat.
I see this mistake constantly. Teams adopt microservices but keep a shared database schema. They call it "modular." It's not. It's a coupling nightmare dressed in Kubernetes YAML.
Real test: Can you delete a table from the shared database without notifying fifteen teams? If no, your architecture has load-bearing walls.
The Horizontal Window — Seeing the Full Picture
Corbusier hated the vertical window. Too narrow. Too much wall. Too many shadows. He wanted a window that stretched the entire length of the facade — a ribbon of glass that gave an uninterrupted horizontal view (The Five Points of Architecture).
Why? Because human vision is wider than it is tall. We evolved to scan the horizon for threats and opportunities. A vertical window fights that biology. A horizontal window embraces it.
The data equivalent is: don't silo your observability by service.
I've walked into too many war rooms where the backend team has their Grafana dashboard showing response times, the data team has their Airflow DAG status, and the infrastructure team has their Kubernetes metrics. Three vertical windows looking at different parts of the same problem. Nobody sees the horizontal view.
When a query times out, is it the database, the network, or the application? If you can't see all three on one timeline, you're debugging blind. Horizontal window means: one pane of glass. Correlated logs. Traces that span services. Metrics that share a common timestamp format.
We built this at SIVARO for a fintech client. They had seventeen monitoring tools. After we consolidated into a single event pipeline with OpenTelemetry traces, their mean time to resolution dropped from 4 hours to 22 minutes. That's the difference between a vertical window and a horizontal one.
The Free Facade — Envelope That Doesn't Enforce
This one's subtle. The free facade means the outer wall doesn't carry load either. It's a curtain. A membrane. It can be glass, concrete, brick veneer — doesn't matter, because it's not holding up the building.
Corbusier put the columns inside the building envelope, set back from the edge. The facade becomes a lightweight screen that can curve, tilt, or change material halfway through ("Five Points of a New Architecture").
In practice, this means: your API gateway shouldn't dictate your backend architecture.
Too many systems have a facade that is the structure. GraphQL endpoints that mirror database tables. REST APIs that expose internal service names. The facade hardens into the architecture, and changing one means rebuilding the other.
Free facade means: put a thin, replaceable API layer between your users and your systems. Version it independently. Let it transform requests into whatever protocol your backend speaks that week. The facade should be the cheapest thing to rewrite — not the most expensive.
At SIVARO, we design facades as pure translation layers. Zero business logic. Zero state. Just request routing, protocol conversion, and basic auth. When a client wants to switch from REST to gRPC on the backend, we don't touch the public API. The facade absorbs the change. That's the free facade in production.
typescript
// Free facade pattern: thin router with zero load-bearing logic
interface ApiGatewayConfig {
routes: Array<{
path: string;
method: 'GET' | 'POST' | 'PUT' | 'DELETE';
targetService: string;
targetEndpoint: string;
transformRequest: (req: HttpRequest) => ServiceCall;
transformResponse: (resp: ServiceResponse) => HttpResponse;
}>;
version: string; // Canary deployment of gateway itself
}
// When backend changes from REST to gRPC, only transformRequest changes
const newBackendConfig: ApiGatewayConfig = {
version: "2.1.0",
routes: [
{
path: "/api/orders",
method: "GET",
targetService: "order-service",
targetEndpoint: "grpc:order.v1.OrderService/ListOrders",
transformRequest: (req) => ({
// REST query params -> gRPC proto
userId: req.query.userId,
limit: parseInt(req.query.limit || "50"),
offset: parseInt(req.query.offset || "0")
}),
transformResponse: (resp) => ({
status: 200,
body: resp.orders.map(formatOrder),
headers: { "X-Total-Count": String(resp.total) }
})
}
]
};
What Are the 5 Principles of Le Corbusier? The Unified System
Here's the thing people miss when they read about these principles individually. Corbusier didn't invent five separate ideas. He invented one system where each part enables the others.
Pilotis make the free plan possible (no ground-floor walls). The free plan makes the horizontal window possible (no interior columns blocking sightlines). The free facade is just the free plan turned outward. And the roof garden compensates for the land you lose underneath.
It's a closed loop. Remove one principle, and the others become harder to implement.
In system design, this is called coherent design surface. Your caching strategy, your database choice, your deployment pipeline — they need to reinforce each other, not fight each other.
Most teams I see implement two of these principles and call it a day. They put the API on stateless servers (pilotis) and build a dead letter queue (roof garden), but they keep a shared database schema between services (no free plan). The result is a system that's half-modern and half-legacy. It works. But it's brittle.
You don't have to implement all five at once. But if you pick three, make sure the other two don't contradict your choices. A horizontal window doesn't help much if your facade is load-bearing.
FAQ: Common Questions About Le Corbusier's Five Points
Q: What are the 5 principles of le corbusier in simple terms?
Pilotis (columns lifting the building), roof garden (usable flat roof), free plan (no load-bearing interior walls), horizontal window (ribbon windows across the entire facade), free facade (non-structural exterior walls).
Q: Did Le Corbusier design Villa Savoye using all five principles?
Yes. Villa Savoye (1928–1931) is the canonical example. Every principle is visible in that building. It's the best single case study for understanding how the principles work together (Le Corbusier's 5 points of modern architecture).
Q: Are these principles still used in modern architecture?
Absolutely. Every building with an open floor plan, curtain wall glazing, or a green roof is using at least one of these ideas. The principles became background radiation in architecture — most architects use them without naming them.
Q: What problem was Le Corbusier trying to solve?
He wanted to make architecture respond to industrial materials (reinforced concrete, steel) rather than masonry. The five points are essentially: "Here's what we can now do because concrete is cheap and strong."
Q: Can these principles apply to software or data systems?
Yes, and that's the whole argument of this article. The decoupling of structure from envelope, the separation of concerns, the compensation loop — these are universal system design patterns, not just building tricks (Since 1922, Le Corbusier has made use of his five ...).
Q: What's the biggest mistake people make when applying these principles?
They treat them as aesthetic choices rather than structural decisions. A flat roof isn't a roof garden unless you use it. An open floor plan isn't a free plan unless the columns are the only structural elements. The principles require enforcement, not just appearance.
Q: Are there any buildings that deliberately violate these principles?
Plenty. The Pompidou Center in Paris puts structure and services on the outside — the opposite of Corbusier's free facade. Frank Gehry's buildings braze complex curves that mock the idea of a simple structural grid. Sometimes breaking the rules is the point.
Q: What should I read next if I want to go deeper?
Start with Vers une Architecture (Towards a New Architecture) by Le Corbusier himself. Then read Reyner Banham's Theory and Design in the First Machine Age for context. For the software connection, read A Philosophy of Software Design by John Ousterhout — it's the closest thing to Corbusier's manifesto for engineers.
Conclusion: Why I Still Think About a 100-Year-Old French Architect
I design data pipelines. I build production AI systems. I spend my days thinking about Kafka partitions, query latency, and schema evolution. Le Corbusier built houses. We have almost nothing in common.
Except we both learned the same lesson: structure is what you can't change easily, so make it minimal.
Pilotis, free plan, free facade — these are patterns for deferring decisions. You put the expensive, hard-to-change decisions in the columns. Everything else is cheap to reconfigure. That's the playbook for building systems that survive their first 100 years.
Next time you're designing a microservice boundary or choosing between a shared schema and a bounded context, ask yourself: am I building a load-bearing wall? If yes, tear it down and put a column there instead.
The building will float. The ground will flow through. And you'll sleep better during on-call rotations.
Nishaant Dixit — Founder of SIVARO. Building data infrastructure and production AI systems since 2018. Built systems processing 200K events/sec.