CONCEPT Cited by 1 source

Objective abstraction¶

An Objective is an enumerated identifier for a business use case in a model-serving platform — a name like ContinueWatchingRanking or PaymentFraudDetection that clients use to address what they want rather than which model to run. The platform owns the Objective → model → cluster-VIP chain; clients never learn the concrete model ID. The Objective is the contract between clients and the serving platform.

Canonicalised on this wiki by the 2026-05-01 Netflix post on model-serving routing, where the Objective is load-bearing for three platform properties: (1) decoupling client code from model iteration, (2) opaque A/B experimentation, and (3) platform-owned model sharding.

Three purposes (per Netflix)¶

The 2026-05-01 post names three things the Objective does:

Identifies the business use case. Any model request must carry an Objective; the platform uses it to scope which rules apply.
Decouples clients from concrete models. Client code calls the platform with Objective = ContinueWatchingRanking, a userId, and a device. It does not name a model. Model swaps (default → experimental candidates, per A/B cell) are invisible to the client.
Drives platform-side routing and model-selection decisions. Given the Objective, the platform looks up the current rule set, resolves the user's A/B cell, picks a model, maps the model to a cluster VIP, and routes.

Example¶

From the 2026-05-01 post:

Objective ContinueWatchingRanking
Input: userId, country, deviceId
Output: ranked list of titleIds
Objective Payment Fraud Detection
Input: userId, country, payment transaction details
Output: probability of fraud

Client services provide these fields; the platform selects the specific model to run based on Switchboard Rules + Experimentation-Platform allocation.

Why it is a wiki-canonical pattern¶

Objective abstraction is the model-serving analogue of several decouple-client-from-backend patterns already canonicalised:

concepts/vip-address-decoupling — at the network layer; Objective is the application-layer complement.
patterns/data-abstraction-layer — at the storage layer; the KV DAL exposes a logical contract that shields clients from physical-store details. Objective abstraction is the model-serving counterpart at the ML workflow layer.
concepts/backend-for-frontend — different intent (per-client shaping vs. use-case identity) but shares the posture of giving clients an abstracted contract rather than raw backend access.

Contrast with model IDs¶

The naive alternative is "clients name the model they want". Concrete failure modes that shape forbids:

Can't A/B test without client changes. A new candidate model requires clients to support "send to model A for cell 1 and model B for cell 2" — pushing experiment logic into every client.
Can't retire old models silently. When a model is deprecated, every client calling it must redeploy.
Can't share infrastructure for multiple models serving the same use case. The platform can't load-balance multiple candidate models because it doesn't know which requests are candidates for each other.

Load-bearing properties¶

Platform-defined enum, not free-form string. The set of Objectives is known to the platform at configuration time; rules can bind to Objectives.X.
One Objective per use case, not per model. A use case may have many models (default, A/B cells, shadow, canary) — the Objective is stable; the model behind it is plural.
Standard request context. Because all Objectives carry similar standard context (userId, country, device) + optional domain context, clients share one API surface across Objectives.

Seen in¶

sources/2026-05-01-netflix-state-of-routing-in-model-serving — first canonical wiki articulation of the Objective abstraction. Load-bearing for Netflix's >30-client, 1M-req/sec model-serving platform. Three purposes enumerated; examples given (ContinueWatchingRanking, Payment Fraud Detection); the Objective is named as "the serving platform's name for a specific business use case".