PATTERN Cited by 1 source
Feature store as policy bridge¶
Pattern¶
Use a feature store as the asynchronous communication channel between policy layers in a hierarchical decision system. The upstream (slow) policy writes its decisions as features; the downstream (fast) policy reads them as input features alongside other signals.
Why feature store (vs. message queue, config push, etc.)¶
- Low-latency reads: Feature stores are optimized for point-lookups at inference time — exactly what the fast policy needs.
- Built-in versioning & persistence: Decisions "stick" until explicitly overwritten by the next slow-policy run.
- Familiar ML abstraction: Both policies already consume features; the plan is just another feature.
- No synchronous coupling: The slow policy can run on its own schedule; the fast policy is never blocked.
- Observability for free: Feature stores typically provide logging, lineage, and freshness monitoring.
Contrast with alternatives¶
| Approach | Drawback |
|---|---|
| Direct API call from fast→slow | Latency spike, tight coupling |
| Config push/pubsub | Extra infra, no per-entity semantics |
| In-memory cache | Lost on restart, no durability |
Seen in¶
- sources/2026-06-19-netflix-thinking-fast-slow-for-a-personalized-notification-system — Netflix's Slow Policy writes personalized pacing plans to a feature store; the Fast Policy pulls the plan as a feature when a send opportunity arises. Netflix credits feature-store architecture as enabling "stickiness" (consistent experience) and independent evolution.