Host Scalability — Static Registry vs Manifest Pipeline
- Status: proposed
- Deciders: Platform Team
- Date: 2026-06-29
- Parent: 0001 — Adopt WhiskerPlatform over rwe-core
Technical Story: Coordination cost vs infrastructure cost at scale
Context and Problem Statement
Section titled “Context and Problem Statement”Both rwe-core and WhiskerPlatform can host the same kinds of UI (federation modules, widgets, iframes). They scale differently as module count and team count grow.
This ADR makes the scalability trade-off explicit so “adopt Whisker” is understood as a scale and operating-model choice, not a quality judgment on rwe-core.
Decision Drivers
Section titled “Decision Drivers”- Host-team PR volume vs module-team count
- Release independence — can Module A ship nav changes while Module B is in host PR review?
- Operational headcount — who runs Lambda/DynamoDB vs who reviews registry PRs?
- Time to add module N — constant vs linear in host coordination
- Failure blast radius — bad registry entry in host repo vs bad manifest isolated per module
Scaling characteristics
Section titled “Scaling characteristics”| Dimension | rwe-core (static registry) | WhiskerPlatform (manifest pipeline) |
|---|---|---|
| Add module N | Host PR(s) + often routes/wrappers/CFN | Module CI only |
| Coordination cost | Grows with modules × host review | Shifts to platform ops (bounded team) |
| Infrastructure cost | Low (S3/CDN per package) | Higher (Lambda, DDB, DLQ, sync GHA) |
| Enable/disable in prod | Code change + host deploy | Admin merge on enabled field |
| Teams at shared cadence | Scales fine (~few modules) | Overhead may exceed benefit |
| Teams on independent cadences | Host becomes bottleneck | Designed for this |
| Cognitive load | Lower (read registry files) | Higher (pipeline + schema + kit) |
Neither row is “always wins.” The crossover point depends on organisation shape, not technology alone.
Considered Options
Section titled “Considered Options”Option A — Optimise rwe-core for scale
Section titled “Option A — Optimise rwe-core for scale”Better registry docs, CODEOWNERS, automated PR templates — stay static.
Option B — Adopt manifest pipeline for scale
Section titled “Option B — Adopt manifest pipeline for scale”Accept infra ops in exchange for removing host as registration gate.
Pros and Cons
Section titled “Pros and Cons”Option A
Section titled “Option A”- Good: no new AWS services; predictable for small platform team.
- Bad: does not remove host PR as serialisation point; registry files grow without bound in one repo.
Option B
Section titled “Option B”- Good: registration work parallelises across module teams; admin toggles without redeploy.
- Bad: platform SRE surface; manifest pipeline failures affect all modules; onboarding tax on every new squad.
Decision Outcome
Section titled “Decision Outcome”Chosen option: Option B — WhiskerPlatform’s manifest pipeline is the
registration model for the single production host (whisker-host).
Option A describes why rwe-core’s static registry worked at smaller scale (few modules, shared cadence, low ops surface). That profile informed the migration decision; it is not a licence to keep rwe-core as a co-production host. See 0001.
Positive Consequences
Section titled “Positive Consequences”- Module count can grow without linear growth in host registry edits.
- Platform ops cost is predictable and centralised vs distributed host review latency.
Negative Consequences
Section titled “Negative Consequences”- Whisker pays infra cost even at low module count during early adoption.
- rwe-core’s lower ops footprint is explicitly traded away at scale.