Mediation

The pattern: instead of letting consumers touch resources directly, route every interaction through a single mediator that enforces policy, accounting, and consistency. The kernel mediates hardware access. The K8s API server mediates cluster state. The service mesh mediates service-to-service calls. The query planner mediates table access. One throat to choke, one place to add audit, one place to optimize.

The trade-off: policy enforcement vs. latency cost. Mediation adds a hop. The benefits — uniform audit, consistent enforcement, single point of optimization — only outweigh the cost when the alternative is “every consumer reimplements the same checks badly.” Some systems bypass mediation deliberately for performance: io_uring shrinks syscall overhead, DPDK skips the kernel network stack, kernel-bypass filesystems exist for the same reason. The cost of mediation is real; you accept it for the property it gives you.

[Deepen in Phase 1; reinforced as you build platform layers in Years 2-5.]

Related patterns

• privilege-separation — mediation is the mechanism by which privilege boundaries are enforced.
• resource-virtualization — the mediator (kernel/hypervisor) is what virtualization runs through.
• layering-and-abstraction — mediators sit at layer boundaries and define the contract there.
• control-loops — the K8s API server mediates and runs reconciliation against the same state.
• service-mesh — mediation pattern applied to east-west service traffic.
• load-balancing — mediation pattern applied to north-south traffic.
• First touched: Year 1 Phase 1: OS Foundations.
• Reinforced in: Year 1 Phase 7: Kubernetes + GitOps (API server), Year 2 Phase 12: Platform Engineering (service mesh).