Skip to content

PATTERN Cited by 1 source

Encapsulate optimization as internal service

Shape: when team A spends years optimizing an infrastructure primitive (a hypervisor topology, a storage substrate, a networking stack) and team B needs the same primitive with the same characteristics, don't give team B the optimizations to re-implement — encapsulate the whole stack as a service team B installs and calls, owned and versioned by team A.

Team B's consumption contract: request resource → use → release. Team A's obligation: every future optimization flows to team B automatically via routine versioning, with zero coordination cost.

Canonical instance: AWS Lambda networking → Aurora DSQL

The AWS Lambda networking team spent "the better part of a decade" optimizing a Firecracker-micro-VM network substrate — eBPF Geneve-VNI rewrite, stateless NAT, per-slot iptables in namespaces, boot-time pre-creation of 4,000 slots.

When Aurora DSQL needed "scalable Firecracker-based networking with the right security and performance characteristics," the Lambda team didn't document a playbook — they encapsulated the full networking stack into a service that DSQL could install and run on their own workers. (Source: sources/2026-04-22-allthingsdistributed-invisible-engineering-behind-lambdas-network.)

The service handles:

  • Device management (tap, veth, bridge, namespace lifecycle)
  • Firewall rules
  • NAT translation
  • Security hygiene for network-slot reuse after release

DSQL's consumption API:

  • Request a network when DSQL needs one for a VM
  • Use it
  • Release it back to the service when done

Werner's framing on the ownership split: "Lambda owns the service and vends new versions, and every optimization they make flows to DSQL automatically."

Disclosed outcome: "saved the DSQL team months of engineering effort and gave them Lambda-grade networking density from day one."

Why this beats the alternatives

  • Copy the code: DSQL would have to track Lambda's optimization pace forever and merge upstream changes. Drift risk: high.
  • Publish a playbook / docs: DSQL builds its own version guided by docs. Optimization-transfer rate: near zero. Drift: high.
  • Build a shared library: better than docs but still requires DSQL to adopt new versions and run them. The operational + security burden remains split.
  • Encapsulate as a service: DSQL pays no integration cost per optimization; Lambda's version-vending model carries improvements across automatically.

Preconditions

  1. The primitive is well-defined: "a Firecracker-backed micro-VM network slot" is nameable, has a clear API surface, has a clear lifecycle (create → use → destroy). Primitives that are deeply entangled with team A's domain-specific concerns don't encapsulate cleanly.
  2. The consumption contract is minimal: request/use/release is roughly the smallest possible API. If team B needs to influence dozens of parameters, the encapsulation is leaky.
  3. Team A accepts product responsibility: owning the service means owning its reliability, upgrade cadence, and multi-consumer support. Team A can't treat it as "we built it for Lambda, you get what you get."
  4. Team B is willing to depend on team A's schedule: DSQL now depends on Lambda's team for networking-substrate changes. If that coupling is unacceptable, don't encapsulate.

Contrast with sibling patterns

Seen in

Last updated · 319 distilled / 1,201 read