Feature Store  ·  View 08 of 21  ·  Structure

Integration Surface

Five ways in, one way to publish a definition, and nothing written back to anything the platform reads.

Editable source SVG draw.io All views
Consumers Online model services 4 at peak Batch scoring Training jobs SageMaker Catalogue users CI pipeline GitHub Actions Feature Store Serving API gRPC, VPC only Registry API REST Training-set service Dependencies Kinesis streams Analytics warehouse Lake Formation IAM / IRSA + KMS gRPC read Iceberg datasets HTTPS publish consume nightly Feature Store — Integration Surface External / third party Person or role Application we own Interface / broker Queue / topic Security / platform synchronous batch event / async Five consumer surfaces, one write surface, and nothing written back to any system the platform reads. Team ownership is resolved from the org directory out of band. v 1.0 · owner Data Platform Architecture · date 2026-09

Decisions

  • The serving API has no public endpoint by design; it is reachable only from inside the VPC, because its callers are all workloads and never browsers.
  • Definitions arrive through CI, not through the API. A feature that can be created by a POST is a feature with no review and no version history.
  • Batch consumers read the offline store directly under Lake Formation grants rather than through the serving API — two access paths because two latency regimes.

Assumptions

  • 320,000 vector reads/second at peak from four online model services, plus 500-key batch lookups from ranking.
  • Team ownership is resolved from the organisation directory out of band, nightly.

Risks

  • A batch consumer reading the offline store directly bypasses per-consumer quotas; a runaway Spark job is bounded by Lake Formation and EMR capacity, not by the platform.
◀  Containers and Components All views Feature Data Flow  ▶
Solution Architecture v1.0 · Amazon Web Services · Data Platform Architecture · 2026-09 · 21 views · 14 architecture decision records08-integration-surface