Compression Floor: Infrastructure Principles from First Principles

The Problem

Infrastructure engineering lacks a shared framework for deciding what to add and what to remove.

Teams accumulate systems. Each addition has justification. Over time, the stack serves itself more than its users. Debugging requires archaeology. On-call becomes heroics.

The usual response: “simplify.” But simplify to what? Without a stopping point, simplification is just aesthetic preference. One engineer’s “clean” is another’s “dangerously minimal.”

We need a boundary. A floor.

Compression Floor

Definition: The compression floor is the minimal configuration where a system still produces its characteristic behavior. Below this threshold, simplification becomes transformation—you’ve built something else.

The concept synthesizes existing ideas:

The compression floor is where essential complexity begins. Everything above it is potentially removable. Everything at or below it is structural.

Note on attribution: The waterbed theory is widely ascribed to Larry Wall in the context of programming language design (particularly Perl/Raku), though no single canonical source paper exists. It is related to but distinct from Tesler’s Law: Tesler addresses the conservation of total complexity, while Wall’s formulation emphasizes the displacement effect—complexity shifting rather than disappearing.

The Operational Test

For any component X:

1. Remove X (or simulate removal)
2. Run the system under production conditions
3. Does the system still produce expected behavior?
4. If yes — X is above floor. Removable.
5. If no — X is at floor. Structural.

Repeat until removal causes failure. That boundary is your floor.

Caveat: Graceful degradation. The binary pass/fail framing is a simplification. In complex adaptive systems, component removal may not cause immediate failure but instead degrade resilience until catastrophic failure under stress (Dekker, 2011; Hollnagel’s resilience engineering). A component may appear removable under normal load but prove essential under edge conditions. Production conditions ≠ all conditions. The test should therefore be run across load profiles and failure scenarios, not just steady-state.

The Sociotechnical Constraint

Technical floor isn’t sufficient. Systems are operated by people.

A component is also structural if operators can’t debug the system without understanding it. If your median on-call engineer can’t reason about a layer at 3am, that layer is operational debt—regardless of its technical elegance.

Revised test: Can the person on-call, six months after the architect left, debug this without escalation?

If no, you’re above the operable floor, even if you’re at the technical floor.

Nesting as Liability

Every nested layer adds:

• A failure domain
• A debugging axis
• A knowledge requirement
• An upgrade coordination cost

These costs are permanent. They compound at 3am.

Default position: avoid nesting unless removal breaks something that cannot be solved at the adjacent layer.

Common honest answer for why nesting exists: org chart, not physics. A platform team needed a product to ship. That’s valid reasoning, but it’s organizational, not technical.

Infrastructure Principles

The compression floor is one principle. It needs company.

Over iterative refinement, we arrived at twelve principles. Each passed the same removal test: does removing this principle leave a gap that remaining principles cannot cover?

The principles also carry Lithuanian proverbs. This isn’t decoration. Folk wisdom that survived centuries did so because it maps to something real. Nassim Taleb’s Lindy Effect provides the theoretical frame: non-perishable ideas that survive do so because they work under real conditions, and grandmother wisdom empirically outperforms academic theory in domains involving uncertainty and skin in the game (Antifragile, 2012).

Principle 0: Security is Paramount

Saugok kaip savo akį — Guard it like your own eye

Security is non-negotiable. Not ROI-optimized. Not balanced against convenience.

Eyes are irreplaceable. You have two, but losing one is catastrophic. You protect them instinctively, without cost-benefit calculation. Infrastructure security works the same way.

Principle 1: Integrity Over Availability

Šaukštas deguto medaus statinę sugadina — A spoonful of tar spoils a barrel of honey

If the choice is corrupted data or system offline—choose offline. A system that serves corrupt data has failed worse than a system that serves nothing. Silence is better than lies.

The proverb captures the asymmetry: small contamination ruins large good. One corrupt write propagates. The barrel is useless after.

Principle 2: Migration is Default State

Pailsėsim grabe / Darbas darbą veja — We’ll rest in the grave / Work chases work

“After the migration completes” is not a system state. It’s a fantasy. Systems are always in transition. Each task generates the next.

Design implication: assume change-in-progress, not change-complete. Blue-green deployments, feature flags, backwards compatibility—these aren’t optional complexity. They’re acknowledgment of physics.

Principle 3: Optimize for Supersystem, Not Local Optima

Kartu mes jėga — Together we are strength

Principle 4: Simplicity

Sudėtingai visi gali. Pabandykite paprastai. — Anyone can make it complicated. Try making it simple.

Nepainiok formos su turiniu. — Don’t confuse form with content.

Kas genialu—tas paprasta. Bet ne atvirkščiai. — What’s genius is simple. But not the reverse.

Three proverbs triangulating one truth: complexity is not achievement, architecture diagrams are not capability, simplicity is necessary but not sufficient. This is the compression floor principle.

Principle 5: Optionality Over Optimism

Nedėk visų kiaušinių į vieną krepšį — Don’t put all eggs in one basket

Kuom tik velnias nejuokauja — The devil jokes with everything

Žmogus planuoja, dievas juokiasi — Man plans, God laughs

Plans fail not because you planned poorly, but because plans are structurally incomplete. Response: don’t plan harder. Have more moves.

Principle 6: Serve Purpose, Not Self

Kas moka—tas užsako — Who pays calls the tune

A system cannot define its own goal. Test: what percentage of system resources serve end function vs maintain the system itself?

Principle 7: Verify Through Action

Ne žodžiais, o darbais mes infrą mylim — We love infra through deeds, not words

Knygoje turi būti tikroviškai, o tikrovėje būna bet kaip — In books it must be realistic, in reality it’s whatever

The map is not the territory. Chaos engineering exists because knygoje ≠ tikrovėje.

Principle 8: Observability

Geriau vieną kartą pamatyti, negu tūkstantį kartų išgirsti — Better to see once than hear a thousand times

Distinct from verification. Verification tests claims. Observability builds capacity to see. If you can’t see it, you’re hearing about it. Hearing scales poorly at 3am.

Principle 9: Capability Over System

Neišradinėk dviračio — Don’t reinvent the bicycle

Function is mandatory. System is optional.

The XY problem at infrastructure scale.

Principle 10: Compound Effort

Lašas po lašo ir akmenį pratašo — Drop by drop wears through stone

Small actions compound. In both directions.

Care is continuous, not incident-driven.

Principle 11: Done is Decision, Not Proof

Geriausias—gero priešas — Best is enemy of good

Ship, observe, iterate. “Done” cannot be proven. It can only be decided. Waiting for certainty that won’t come is its own failure mode.

Principle 12: Respect Defaults

Nežinai brastos—nelįsk į vandenį — Don’t know the ford—don’t enter water

Defaults exist for reasons. Understand before overriding. Chesterton’s fence: before removing a fence, understand why it was built.

The Complete Set

Application

The principles are constraints, not procedures. They don’t tell you what to build. They tell you what questions to ask before building, during building, and when deciding whether to keep what you built.

Use them as:

• Design review checklist: Does this proposal violate any principle?
• Incident postmortem lens: Which principle was violated?
• Architecture decision records: Which principles drove this choice?
• Onboarding material: What does this team believe about infrastructure?

The Lithuanian proverbs serve a specific purpose: they make the principles memorable and culturally sticky. Abstract principles drift. Proverbs survive. As Taleb argues, this survival is not incidental—it is the strongest available evidence that the encoded heuristic works under real conditions.

Your grandmother already knew most of this. That’s the point.

Sources

The compression floor concept synthesizes: Brooks, Fred. “No Silver Bullet” (1986); Tesler’s Law of Conservation of Complexity; Kolmogorov complexity (1965); Wall, Larry. Waterbed theory (ascribed).

The principles draw from: Google SRE Book; Chesterton, “The Thing” (1929); Taleb, Antifragile (2012) and Skin in the Game (2018); Larson, “An Elegant Puzzle” (2019); Conway’s Law; Erlang philosophy; Dekker, Drift into Failure (2011); Hollnagel’s resilience engineering; Lithuanian folk wisdom.

Compression floor: the boundary where essential complexity begins. Target it. Don’t go below. Don’t stay above.