At a glance
The new format did not fit cleanly into the assumptions of the existing serving pipeline. Supporting it required new classification and matching behavior without changing how existing traffic was served.
I led the serving-side design and implementation, including classification, routing, matching changes, guardrails, tests, and the staged rollout.
The format launched successfully through a staged rollout, with no observed regression in the existing serving behavior.
The challenge
The new format did not fit the existing serving assumptions
The serving pipeline already had well-established behavior for the existing request types. The new format reused some of the same request structure, but its meaning and matching requirements were different.
That meant support could not be added safely by changing one isolated condition late in the pipeline. We needed a reliable way to recognize the new inventory early and preserve that meaning as the request moved through the existing serving flow.
Constraint
The first release had a tight deadline
A dedicated model for the new format was the cleaner long-term direction, but introducing it immediately would have required coordinated changes across more of the stack. That broader scope put the first-release deadline at risk.
We chose to keep the first release smaller, reuse the existing model where it was safe, and leave a path toward the dedicated model later.
Architectural choice
Classifying the new inventory early
The serving-side design added an early classification step based on the request signals available at that point in the pipeline. Once identified, the request carried an internal semantic signal so downstream stages did not need to reinterpret the original request fields.
The existing pipeline could remain shared, while the new format entered its own matching behavior only where the distinction actually mattered.
Serving-side design
Guardrails
Keeping the existing path stable
The new behavior was intentionally bounded to requests that had been classified for the new format. Existing traffic continued through the established path.
- 01Classify correctly
Only requests that matched the expected signals entered the new behavior.
- 02Match compatible inventory
Format-specific matching remained isolated from the existing behavior.
- 03Control exposure
Tests, configuration gates, and staged exposure gave us ways to validate the new path before expanding traffic.
Architectural sequencing
Why we shipped the incremental model first
Dedicated model
- Cleaner semantics
- Easier to extend
- Larger cross-stack scope
- More work before first launch
Incremental first release
- Reuse existing model and path
- Smaller initial scope
- Faster first delivery
- Migration work remains
We chose the incremental model for the first release because it kept the required changes contained. The dedicated model remained the cleaner direction for future evolution.
Release
Rollout
- 01Implementation
and tests - 02Staged
rollout - 03Pilot
validation - 04Launch
The serving changes were covered by tests before exposure increased. We then rolled the new behavior out in stages, validated it with a pilot, and expanded to launch while watching for regressions in the existing path.
Trade-off and reflection
What I would make clearer next time
The incremental approach helped us meet the first-release goal, and I still think the sequencing made sense. Where I would improve the process is in making the follow-up cost more explicit from the beginning.
I underestimated some of the complexity the temporary model would create outside the serving-side work. If I made the same sequencing decision again, I would want a clearer migration scope, an owner for the follow-up, and an explicit trigger for moving to the dedicated model.
My contribution
Leading the serving-side work
I owned the serving-side design and implementation for the new format. That included the early classification approach, carrying the internal signal through the pipeline, isolating the new matching behavior, adding guardrails and tests, and following the change through staged rollout.
The broader delivery involved other parts of the stack and other engineers. My responsibility was the serving-side portion and the technical decisions required to integrate the new behavior safely there.
Current status
Launched through a staged rollout.
The format shipped successfully after the staged rollout and pilot validation. We did not observe regressions in the existing serving behavior during the launch.