Feature platform

What, when, why and how

Clarify the platform and the decision

We serve governed features to recommendation/ranking consumers and construct permitted historical datasets. The platform itself predicts no target: its labels are correctness/availability test outcomes, not click labels. A simple SQL/batch pipeline and cache are the baseline. Production databases, streaming infrastructure and authorization are described contracts; this repository executes bounded fixtures.

These six assumed answers define an interview scope. All rates, deadlines, IDs and values are original synthetic assumptions, not a vendor architecture or measured deployment.

Change the design when the answer changes

Branch A: if batch freshness meets the use case, keep reviewed SQL over immutable source snapshots, schedule bounded materialization and retain sufficient activation evidence. Avoid a stream processor, distributed watermark state and multiple serving stores until there is a measured need.

Branch B: if immediate per-session context drives value, compute bounded permitted request-time inputs or introduce an incremental pipeline with declared windows, watermark/correction semantics and failure policy. Do not reuse an hourly feature under a seconds-fresh contract. If exact past serving visibility was never recorded, disclose the replay gap and offer separately named corrected-history analysis.

Define correctness before popularity

The platform objective is trustworthy reusable inputs at acceptable latency/freshness/cost. Success is not the number of registered features or a consumer AUC increase attributed without an experiment. Domain/model consumers still own predictive targets and product evaluation.

Primary evidence includes eligible replay source-ID agreement, contract violations, successful publication/read availability, freshness/default rates, tenant isolation and checkpoint/deletion tests. Count rejected/failed cases explicitly; a low-latency default response is not equivalent to a fresh measured value.

Make the SQL and cache baseline usable

Define activity_v1 in reviewed SQL against an immutable permitted snapshot. Persist entity-qualified values with source/definition/transform and coverage timestamps. A scheduled job validates outputs and conditionally populates an online key/value cache. A batch retrieval call checks access/freshness and returns value/status/provenance.

This baseline already supports repeatable offline joins if timestamps and activation evidence are real. It lacks sub-hour updates, fine-grained stream corrections and automatic cross-team discovery. Add a registry when shared definitions/ownership become hard to manage; add streaming when quality/freshness evidence warrants its operational cost. A registry is metadata, not a running materializer.

Write the v1 definition and compatible bundle

Our scalar fixture is activity for tenant T1/entity U1, version v1, count unit, finite number, scale-10-v1 transform, raw default zero and maximum age 3,600 seconds. The illustrative consumer formula is 2*(raw/10)+1; it is fixed arithmetic, not a trained model. Here activity is the count of permitted successful actions in the trailing hour [coverage_end - 1 hour, coverage_end). The fixture consumes the already-computed count, with eventAt equal to coverage_end: F1 covers [08:00,09:00), F2 [08:30,09:30). Their counts are 10 and 40. Source input selection/dedup and range validation happen upstream; this fixture does not compute these windows.

A bundle orders required/optional features, definitions, transforms, defaults, model input schema and consuming release. A /100 transform or count-to-rate change is a breaking semantic v2 even if shape/type remain identical. Old/new namespaces may coexist only under explicit permitted support and cost limits.

Validate producers before accepting effects

Ingest an envelope with event identity, source contract version, tenant/entity, epoch, event time, source revision sequence, payload and digest. Authenticate producers and derive trusted scope; validate field types, ranges, source clock bounds and definition compatibility. Quarantine malformed/conflicting records with reason counts and a bounded repair path.

An acknowledgement means durable accepted input, not online availability. Record ingestion, validation and successful activation separately. Deduplicate by semantic payload and stable event identity; a replay with reordered JSON keys is still the same effect. Conflicting payload under one event ID is an error, not an update. A real aggregate must deduplicate input contributions before counting.

The implemented projector receives only current state and one candidate. Its retry/conflict checks cover that current identity; a production producer/event ledger must preserve dedup identities across superseded events and validate retries before projection. The pure example does not claim full-stream deduplication or source authorization.

Define stream windows and corrections

For an aggregate, specify event-time window bounds, event eligibility, dedup identity and coverage clock. A watermark is a declared completeness/latency trade-off, not proof no later event exists. Bound retained state and define what happens to events beyond the allowed correction horizon.

Within the correction horizon, publish a new revision under source order and record its actual activation. Beyond it, route to audited repair/corrected-history generation or reject under policy; never silently backdate a serving interval. The implemented scalar fixture accepts already-computed feature values; it does not run a streaming window engine.

Walk the temporal contract with real boundaries

F1 has event 09:00, raw 10, actual online availability 09:01 and supersession 10:10. F2 has event 09:30, raw 40 and actual online availability 10:10 with no end. At 10:00, replay reads F1. At exactly 10:10, F1 is no longer active and F2 becomes active. At 10:15 read F2.

At 10:30 F2 age is exactly 60 minutes and remains valid under the inclusive convention. At 10:45 it is 75 minutes old: return stale/default raw zero plus F2 provenance. A tenant T2 row with value 999 is never eligible for T1. Overlapping active intervals are a contract error. A generation-1 historical record is ineligible after current authority moves to generation 2.

These are serving-state replay rules. Corrected history may choose corrected values under a separately declared cutoff/policy; give it another snapshot identity and do not call it exact replay. If invalid data once actually served, preserve permitted incident evidence and distinguish actual observations from a cleaned analytical reconstruction.

Express the join and index its access path

The independent SQLite oracle selects exact tenant/entity/definition/version/epoch, event_time <= :T, available_at <= :T and (:T < superseded_at OR superseded_at IS NULL). It rejects more than one active row and checks age relative to :T. The synthetic UTC text encoding is canonical and ordered; production timestamp types should avoid arbitrary timezone-string comparisons.

Index the compound identity with interval/event columns based on query plans and partition large historical joins by dataset/tenant/time. A temporal predicate alone is not an efficient all-pairs join. Prepartition candidate ranges, bound examples/features and report scan amplification. Apply current export authorization and deletion guards outside/alongside the temporal query; SQL chronology cannot authorize a caller.

SELECT * FROM available_value
WHERE tenant = :tenant AND entity = :entity
  AND definition = :definition AND version = :version AND epoch = :epoch
  AND event_at <= :at AND available_at <= :at
  AND (superseded_at IS NULL OR :at < superseded_at);
-- Require <= 1 active row; then evaluate age at :at.
-- Trusted current access/generation guards also apply.

Publish current values without arrival-order corruption

The pure projector compares source event time then revision sequence within tenant/entity/definition/version/epoch. An identical ID and payload is a no-op; a conflicting retry or equal source order with different identity is rejected. An older source order is retained offline but cannot replace current state or create a fictitious online activation.

In production, perform expected-pointer/generation validation, closure of the old active interval, insertion of the new activation and pointer change atomically where possible. If stores are separate, choose an authoritative commit log, durable outbox/idempotent projection and reconcile by commit version. A crash between cache write and interval logging otherwise breaks exact replay. Record actual acknowledgement/activation guarantees rather than promising cross-store atomicity.

The interval fixture assumes one coherent authoritative serving namespace. Replicas or caches may serve older values after authoritative activation; then this ledger alone reconstructs the authoritative view, not necessarily the exact request input. Record each decision’s returned source/commit versions and observation time, or enforce a compatible read fence, to replay the actual inputs. Measure and state replica/cache consistency and clock-order limits rather than treating wall-clock timestamps as a global transaction order.

Make read, export and write acknowledgements precise

POST /feature-sets/read accepts an authenticated entity context, approved bundle and bounded list, not arbitrary SQL. It returns request/bundle/definition IDs, values, status, source references, event/coverage/availability times, generation and server observation time. Pin one read snapshot where available; otherwise expose per-feature observation versions and do not claim a cross-store atomic vector.

POST /datasets creates a bounded asynchronous job over example timestamps and pinned feature contracts plus replay/corrected mode. Admission returns a job ID, not completed rows. Export delivery rechecks current permission; GET job status distinguishes admitted, running, ready, failed and revoked. Producer ACK means durable ingestion; materialization ACK means the specified publication committed. Retries carry stable IDs. Timeouts have ambiguous effects and must be resolved by idempotency/status, not a fresh request identity.

Backfill in bounded reproducible chunks

A backfill run pins input snapshot INPUT1, definition v1, transform scale-10-v1, target namespace, tenant/entity generation and expected checkpoint version. Each chunk names a stable ID, half-open row range, row count and content digest. BF1 starts cursor 0/version 1; chunk C1 covers [0,2), commits cursor 2/version 2, and an identical retry returns unchanged state.

A different digest under C1 is rejected; a new chunk starting from a stale cursor/version is rejected. Publication checks current authority even if the job was admitted earlier. Outputs plus checkpoint must commit atomically or use deterministic output keys and reconciliation, otherwise advancing the cursor can skip lost data. The pure fixture updates metadata only and does not write outputs or prove distributed exactly-once effects.

Backfills do not rewrite old activation intervals. Historical results go to a new snapshot; any current-value projection still obeys monotone source order. Bound chunk rows, scan bytes, parallelism, retries and tenant budget; isolate backfill pools from serving and include cancellation/partial-run cleanup.

Execute independent goldens before comparing scores

For raw 40 under scale-10-v1, transformed value is 4 and the fixed score is 9. Raw 10 gives score 3. The wrong /100 transform would give .4 and score 1.8, but semantic validation rejects that bundle before a numeric tolerance is consulted. Missing/stale default raw zero gives score 1 only under this declared optional-feature consumer. Deleted data returns null and cannot be scored.

Compare exact entity/version/generation, source ID, active interval/status, feature order and transform first. Then compare raw/transformed numbers under a scoped tolerance such as 1e-9 for this scalar fixture. Test empty/invalid numbers, missing, stale, late arrivals and old-generation paths. Pair sampling from shadow reads must align the same as-of question and access conditions.

This problem trains no model, estimates no AUC and runs no experiment. Consumer model training would pin dataset examples and split by decision time/entities with availability/label-maturity constraints from the relevant problem chapter. Platform correctness is necessary input evidence, not proof of product lift.

Use the entity model as an executable design conversation

The following logical schema separates definition/source, event and successful activation, online pointer, run/chunk, bundle, snapshot/example, observed lineage and deletion state. Every FK has a rendered parent/child relationship and cardinality. Globally opaque IDs identify rows; composite tenant/entity/definition/epoch constraints enforce compatible references beyond basic FK existence.

Scalar columns are a design representation; JSON fields have versioned validated schemas. Historical partitions and append logs may be physically different from the transactional pointer store. Choose storage/indexing after access patterns and consistency guarantees. The SQLite oracle models activation selection only; it does not instantiate this full production schema or any real database migration.

Budget serving, history and repair together

At 5,000 requests/s and 20 features, naive per-feature calls create 100,000 calls/s before retry amplification. Batching cuts round trips but keys/bytes/partitions still cost work. Assume a 20ms platform budget only as an interview target; measure queueing, cold-key misses, authentication and p99 under skew rather than adding mean component timings.

10M entities * 20 values * 8 bytes = 1.6GB raw scalar values (decimal). Keys, contract metadata, timestamps, indexes, replicas, history and old/new bundles add substantial overhead. A historical table retaining repeated activations can dominate current values. Estimate update rate * average bytes * retention and bound replay scan/output sizes.

If a repair reads 100M rows at a sustained measured 50k rows/s, ideal scan time is 2,000s (~33.3 minutes) before shuffle, validation, output and retries. These are hypothetical inputs. Benchmark producer skew/hot entities and per-tenant cost. Increasing workers can saturate the serving dependency; apply admission/pool isolation before scaling concurrency.

Roll out definitions and roll back compatible bundles

Validate schema/semantic goldens and independent temporal tests first. Dual-compute a v2 namespace under quotas, shadow aligned requests, compare source/status/transform and freshness, then promote a compatible model-feature bundle by controlled canary. Predeclare stop gates for contract failures, deletion leaks, stale/default spikes, latency and downstream quality.

Keep a permitted compatible old bundle and data namespace for rollback during an explicit support window. A v2 count-to-rate migration cannot point an old model at the new values. If old data is revoked or its source no longer exists, old-bundle rollback is unavailable: contain/degrade using an approved baseline and rebuild a compatible release. Never undo deletion or silently lower a required freshness policy to make rollback work.

Operate freshness and correctness with owners

Domain owners monitor source semantics/completeness and corrections; platform owners monitor ingestion lag, rejected conflicts, activation lag, projector/version divergence, checkpoint age, p99/default rates, tenant cost and deletion propagation; consumer owners validate model behavior under status/fallback changes. Tie alerts to an owned action rather than a dashboard count.

A freshness incident: producer stops, cache latency stays low, measured values age out, default rate rises. Identify affected definitions/bundles, contain with approved fallback, pause unsafe promotion, restore producer/materialization and validate replay without moving old activation timestamps backward. Backfill under quotas and document the quality impact/unknowns. A platform cannot fix this by retraining automatically on corrupted history.

Fence deletion and restrict historical exports

Authority for T1/U1 generation 1 advances to generation 2 with access revoked. Read/export paths deny/no-value immediately under that authority, even when old snapshots remain stored. A delayed generation-1 materializer or backfill chunk fails at publication. If the identity is legitimately recreated at generation 2, old generation-1 data is still ineligible. Cache keys include epoch and reads validate authority freshness according to the policy.

Use observed lineage to locate sources, offline partitions, exported examples, online pointers/caches and downstream consumers. Track owned acknowledgements for invalidation, access restriction, redaction/rebuild and remaining failures. Revocation containment, physical removal from supported artifacts and model-influence remediation are separate milestones. Define policy-specific retention, auth-cache revocation bounds and permitted audit metadata; a graph or source-row deletion alone proves none of these.

Review normal, boundary and failure traces

Normal: accepted F1 activates at 09:01, a 10:00 replay returns raw 10/score 3, F2 activates at 10:10, a 10:15 read returns raw 40/score 9. An identical producer retry does not move activation time. A late event from 09:15 is ignored for current projection.

Boundary: at 10:10 only F2 is active; at 10:30 its age equals 3,600s and is usable; at 10:45 it is stale/default. Empty entity yields missing/default only for the optional feature; cross-tenant access is denied before lookup. Two active rows signal a corrupt contract rather than an arbitrary winner.

Failure: C1 commits cursor 2/version 2 and loses its ACK; identical retry does not double-advance. Conflicting retry fails. A generation barrier advances while the worker is paused; its resumed old-epoch chunk fails even with a previously valid checkpoint. A wrong transform fails semantic validation before a plausible score can be returned.

Defend alternatives and the Staff boundary

Latest-only cache is cheap for current reads but insufficient for exact serving replay. Warehouse SQL is flexible for bounded offline datasets but expensive/unpredictable in a synchronous request path. A stream processor improves freshness only with added state/correction/operational costs. An external feature-store framework can implement selected contracts; test provider/version behavior rather than assuming its defaults solve your exact semantics.

Staff work aligns definition ownership, consumer migrations, tenant isolation, allowed retention/replay, cost allocation and incident handoffs across teams. Negotiate a supported contract matrix and evidence for adoption; feature count is not the objective. Search and bot detection remain future pilot chapters; unwritten prerequisite lessons are shown as scoped previews rather than falsely complete content.

Data model, schema and relationships

Seventeen logical entities distinguish semantic definitions, accepted source events, actual serving activation, checkpointed jobs, ordered consumers, historical examples and lifecycle propagation. Every FK is rendered with cardinality; required conceptual entities retain stable IDs.

Implementation boundary: Production design contract only. Independent SQLite instantiates a scalar activation ledger for temporal selection; JavaScript uses bounded in-memory records. No live registry, migrations, access provider, full persistence or stream service is installed.

These are proposed logical schemas with field contracts, not executable database migrations. PK identifies a row, FK references an existing parent, UK is a uniqueness rule. A composite PK identifies the combination. Nullable references are marked with ?. A foreign key protects identity; cross-row limits, timing and state transitions also require the transaction rules below.

Entity definitions and field contracts

Relationship cardinalities and their reasons

Diagrams and relationships

Engineer, Senior and Staff follow-ups

These are teaching lenses. Each answer changes the scope of reasoning; they are not official employer leveling criteria.

Practice and self-review

Progressive hints

Evidence to check in your answer

• Engineer: coherent baseline, complete semantic definition, precise API/status and temporal boundary math.
• Senior: conditional projection, bounded idempotent backfill, independent parity tests, schema/index/atomicity and failure recovery.
• Staff: ownership, tenant resource/access boundaries, migration/retention/rollback constraints and cost evidence.
• All levels: distinguish executed fixtures from production guarantees, independent review and consumer quality.

For each item, record Missing, Prompted, Independent or Adaptive evidence. Adaptive means you can revise the reasoning under a changed constraint. Reading completion and readiness are separate.

Sources and verification scope

Original synthetic examples and reference calculations. Sources support narrowly scoped background; they do not establish production performance or independent chapter review.

Rules of Machine Learning ↗ · Baseline/infrastructure and training-serving consistency principles; dated examples are not current architecture claims.

Feast point-in-time joins ↗ · Historical feature retrieval reference; actual availability/revision contracts still need explicit modeling.

NIST AI Risk Management Framework ↗ · Risk vocabulary and governance; not a certification or blanket legal-compliance guarantee.

Feast feature retrieval ↗ · Offline/online retrieval and contract vocabulary only. Original activation-interval fixture is platform-neutral; no Feast integration or provider/default guarantee.

OpenLineage object model ↗ · Job/run/dataset and observed lineage vocabulary only. No OpenLineage SDK, authorization or deletion guarantee is implemented.

Primary background links checked during authoring on 2026-10-19. Arithmetic, temporal eligibility, maturity and split reference functions are checked by the bounded local fixture suite. SQL is explanatory, not a migrated production query. No GPU, external dataset, model API or training job is required.