Baggage Management System (BMS) — AWS Serverless Architecture

Baggage Management System (BMS) — AWS Serverless Architecture

1. System Context

Baggage flows through distinct checkpoints, each generating an event: Check-in → Security/Screening → Sortation → Load (Aircraft) → Transit/Transfer → Arrival → Carousel/Claim → (Lost/Found, if applicable). Each checkpoint scan (RFID/barcode) needs to be captured, processed, correlated with the passenger/PNR, and made available for real-time tracking, ops dashboards, and passenger-facing apps.

2. High-Level Architecture (Event-Driven Serverless)

[Scanner/RFID/IoT Devices @ Airport]
        │ (MQTT/HTTPS)
        ▼
   AWS IoT Core  ──────────────┐
        │                      │
        ▼                      │
  Kinesis Data Streams         │
   (baggage-scan-events)       │
        │                      │
        ▼                      │
   Lambda (Event Enricher) ────┘── enrich with PNR/flight data (DynamoDB lookup)
        │
        ▼
   EventBridge (Custom Bus: bms-events)
        │
   ┌────┼─────────────┬───────────────┬─────────────────┐
   ▼    ▼             ▼               ▼                 ▼
 Step   DynamoDB    SNS (Passenger   OpenSearch        S3 (raw event
Functions (state)    notifications)  (ops search/      archive, data lake)
(mis-route                            analytics)
 handling,
 exception flow)

3. Core Components

Layer AWS Service Purpose
Ingestion AWS IoT Core / API Gateway (HTTP) Receives scan events from RFID readers, handheld scanners, sortation system PLCs
Streaming Backbone Kinesis Data Streams (or Kinesis Data Streams + Firehose) Durable, ordered, high-throughput ingestion of scan events per bag tag ID
Compute Lambda (Node.js/Java) Event enrichment, validation, business rules (e.g., mis-route detection), routing decisions
Orchestration Step Functions Multi-step bag journey workflows — exception handling (mis-routed bag, short-connection re-route, lost bag investigation)
State Store DynamoDB (single-table design) Bag status (current location, last scan, ETA to gate), PNR↔Bag tag mapping, flight-bag manifest
Event Bus EventBridge Decouples producers (scan ingestion) from consumers (notifications, analytics, ops dashboard)
API Layer API Gateway + Lambda REST/GraphQL (AppSync) APIs for passenger app “track my bag”, ground staff app, ops console
Real-time Push AppSync (GraphQL subscriptions) or API Gateway WebSocket Live bag status updates to passenger mobile app without polling
Notifications SNS + SES “Bag loaded,” “Bag delayed,” “Bag at carousel X” alerts via push/SMS/email
Async Decoupling SQS (+ DLQ) Buffer between EventBridge and slower downstream consumers (e.g., baggage reconciliation system, IATA Type B messaging)
Search/Ops Dashboard OpenSearch Service Ops team searches “where is bag X,” anomaly dashboards, SLA breach monitoring
Analytics/Reporting Kinesis Firehose → S3 → Athena/Glue → QuickSight Mishandling rate, transfer SLA compliance, carousel dwell time trends
Identity Cognito Passenger app auth; IAM roles + Cognito for staff/ops console
CDN/Frontend CloudFront + S3 Static hosting for passenger web/app assets
Security WAF, KMS, Secrets Manager, IAM (least privilege) API protection, encryption at rest/in transit, credential management for legacy system integration (e.g., IATA BSM/BUM messaging via SITA/ARINC)
Observability CloudWatch, X-Ray, EventBridge Schema Registry End-to-end tracing of a bag’s event chain, distributed tracing across Lambda/Step Functions

4. Key Design Decisions

Bag tag ID as partition key — DynamoDB single-table design keyed by BAG#<tag_id> with sort keys for EVENT#<timestamp>, STATUS#current, enabling both point lookups (track this bag) and chronological journey reconstruction.

EventBridge as integration spine — Keeps the system loosely coupled from legacy airport systems (BHS/Baggage Handling System PLCs, IATA Type B telex messages like BSM/BPM). A Lambda-based adapter can translate IATA messages into internal events and publish to the same bus.

Step Functions for exception paths only — Happy-path scans are simple Lambda + DynamoDB writes (low latency, low cost). Step Functions is reserved for multi-step exception workflows (mis-routed bag recovery, short-connection rebooking, lost-bag claim processing) where state, retries, and human-in-the-loop (ops agent) steps matter.

Multi-region active-active (carried over from your prior BMS doc) — Given airline operations span multiple hub airports, DynamoDB Global Tables + Kinesis regional streams with cross-region EventBridge replication can be layered on for hub-level resilience, with Route 53 latency-based routing for the passenger-facing API.

5. Non-Functional Considerations

  • Scale: Kinesis shard count sized for peak scan rate per hub (e.g., shift-change/peak departure banks)
  • Resilience: SQS DLQs on every async hop; Step Functions retry/catch on legacy system integration calls (these are often the least reliable link)
  • Latency: AppSync subscriptions for passenger-facing “live” tracking; sub-second target from scan to UI update
  • Compliance: IATA Resolution 753 (bag tracking at 4 checkpoints) drives the minimum event set you must capture and retain
  • Cost: Kinesis + Lambda + DynamoDB on-demand scales naturally with flight schedule seasonality; avoid over-provisioning for off-peak