Principle:Tensorflow Serving Servable Identity And State
| Knowledge Sources | |
|---|---|
| Domains | Model Serving, Core Framework |
| Last Updated | 2026-02-13 00:00 GMT |
Overview
The Servable Identity and State principle establishes the foundational type system for identifying, tracking, and transporting versioned servable objects through the TensorFlow Serving pipeline.
Description
TensorFlow Serving uses a layered type system to represent servables as they flow from Sources through SourceAdapters to Managers:
Identity: Every servable is uniquely identified by a ServableId, which pairs a stream name (the model name) with a version number. This two-part key supports both explicit version requests and "latest version" routing. The identity is immutable once assigned and serves as the primary lookup key throughout the system.
State: A servable's lifecycle within a Manager is represented by ServableState, which captures the servable's identity, its current ManagerState (Start, Loading, Available, Unloading, End), and its health status. State transitions are unidirectional (from Start toward End) and are published on an EventBus for monitoring.
Data Transport: The ServableData<T> template acts as an envelope that pairs a ServableId with either a data payload or an error status. This is the unit of data that flows through the Source/SourceAdapter pipeline. The most common instantiation is ServableData<StoragePath>, where StoragePath is a string alias representing a file system path.
These types are deliberately simple value types with minimal behavior, enabling them to be efficiently copied, moved, and compared across thread boundaries.
Usage
Apply this principle whenever defining or working with servable metadata in the serving pipeline. Use ServableId as the canonical key for servable lookup. Use ServableData<T> for transporting typed payloads through Sources and Adapters. Use ServableState for lifecycle monitoring via EventBus.
Theoretical Basis
The identity and state model follows a typed envelope pattern common in message-passing systems:
Envelope := (Identity, Payload | Error) Identity := (StreamName, VersionNumber) State := (Identity, LifecyclePhase, HealthStatus)
Key design properties:
- Immutable identity: Once assigned, a ServableId does not change, enabling stable hashing and comparison.
- Unidirectional state machine: The ManagerState enum enforces a monotonic transition order (Start -> Loading -> Available -> Unloading -> End), preventing invalid state regressions.
- Error-or-data duality: ServableData carries either valid data or an error, but never both. This is analogous to a Result/Either type, ensuring error propagation without silent data loss.
- Value semantics: All identity and state types are designed as lightweight value types suitable for copying across thread and module boundaries.
The Fibonacci hashing used in HashServableId (based on Knuth's multiplicative hash) provides excellent distribution for sequential version numbers, which is the common access pattern.