PATTERN Cited by 1 source
API parity migration¶
Maintain full API compatibility with the existing system while replacing internal components, so consumers experience zero disruption during the migration.
Context¶
You need to replace the internals of a platform (scheduler, storage engine, networking layer) but your users depend on the current API contract.
Solution¶
Keep the existing API surface unchanged. Replace the underlying implementation behind it. Migrate internal mappings from old abstractions to new ones (e.g., tenants → Cohorts, queues → ClusterQueues). This "unstacks bets" — you validate the new backend without simultaneously changing the consumer contract.
At Netflix¶
When migrating from CMB to Kueue, Netflix kept the CMB API surface identical. Under the hood, internal tenants became Kueue Cohorts and leaf tenants became ClusterQueue + LocalQueue. Users continued to submit jobs and manage tenants through the same interface. The migration required "zero lift for CMB end users and [was] completely transparent to them."
(Source: sources/2026-06-22-netflix-how-netflix-simplified-batch-compute-with-kueue)
Seen in¶
- sources/2026-06-22-netflix-how-netflix-simplified-batch-compute-with-kueue — Netflix's zero-user-impact migration from CMB to Kueue.