SYSTEM Cited by 1 source
Amazon Key¶
Amazon Key is Amazon's physical-access-management product family — consumer-side In-Garage Delivery (couriers unlock + place packages inside customers' garages) and business-side access management for apartment buildings / gated communities (property managers grant delivery-only access for residents). Devices span smart garage door openers, smart locks, access control for commercial entries, and the cloud-side orchestration that ties delivery-courier workflows to access-grant events.
Role for this wiki¶
Amazon Key is the production instance of the single-bus multi-account + event-driven architecture articulated in the 2026-02-04 AWS Architecture Blog post. The system went through a named migration from a tightly coupled monolithic service-interaction design to EventBridge-centric pub/sub with a schema repository + client library + reusable subscriber constructs.
Pre-migration failure modes (named in the post)¶
- Cross-service cascade: "an issue in Service-A triggered a cascade of failures across many upstream services, with increased timeouts leading to retry attempts and ultimately resulting in service deadlocks".
- Single-vendor blast radius: problems with one device vendor, scoped to one specific delivery operation, caused fleet-wide degradation across multiple system services.
- Loose event schemas: no explicit schemas, no validation, no deprecation path, no cross-team collaboration surface.
- Ad-hoc SNS/SQS pairs: per-integration SNS+SQS pairs between services, implemented inconsistently, no standardisation, additional maintenance overhead — classic "growing-pains" microservices anti-pattern.
Post-migration architecture¶
- Ownership split: service teams own application stacks + business logic; central DevOps team owns the shared EventBridge bus + rules + targets + service integrations.
- Schema repository (custom, distinct from EventBridge's built-in registry): JSON-Schema Draft-04; versioned; build-time code bindings; audit trail; deprecation policies; cross-team collaboration surface.
- Client library: type-safe event creation, pre-publish validation, serialization/deserialization, publish/subscribe abstractions; credited with "addressing 90% of common integration errors".
- Subscriber constructs library (AWS CDK): ~5-line CDK declaration provisions per- subscriber event bus + cross-account IAM + monitoring + alerting.
Reported production metrics (post-migration)¶
| Dimension | Value |
|---|---|
| Throughput | 2,000 events/second |
| Success rate | 99.99% |
| End-to-end latency | 80ms p90 (ingestion → target invocation) |
| Subscriber calls | 14,000,000 in reporting window |
| New-use-case integration | 5 days → 1 day (−80%) |
| New-event onboarding | 48h → 4h |
| Publisher/subscriber integration | 40h → 8h |
| Integration-error coverage | 90% via client library |
| Event-bus infra governance | 100% single control plane |
| Unauthorized-data-exchange detection | 100% automated |
(Source: sources/2026-02-04-aws-amazon-key-eventbridge-event-driven-architecture)
Related¶
- systems/amazon-eventbridge — the substrate.
- patterns/single-bus-multi-account — the organisational pattern.
- patterns/client-side-schema-validation — the validation pattern.
- patterns/reusable-subscriber-constructs — the subscriber-IaC pattern.
- concepts/event-driven-architecture — the architectural style.
- concepts/service-coupling — the failure-mode framing pre-migration.
- concepts/schema-registry — the governance primitive.