Pulse doesn't pick one tool for everything. Each layer is chosen against the specific failure mode a live event can't afford.
Greengrass-managed edge hardware, on-device ONNX inference
On-device ONNX for the critical path, hybrid pre-generation for economics
Kinesis Data Streams (live ops) + Firehose (analytics), in parallel
ECS Fargate default, EKS for GPU-backed workloads
DynamoDB+DAX (durable) / ElastiCache Redis (ephemeral)
Pre-provisioned capacity serves attendees at doors-open
Where inference actually runs on venue hardware, and how fleets of that hardware get managed.
Fleet management and OTA updates across multiple venues — the right call once Pulse is a repeatable, multi-event platform.
Simpler for a true one-off event with a single venue and no ongoing fleet to manage.
Only justified for a permanent venue installation, not a touring event footprint.
No single inference strategy covers both "must survive a dropped connection" and "can tolerate a couple seconds of latency."
Survives dropped connectivity entirely. Capped by whatever compute the venue hardware has, and can't be updated mid-event.
Moves most generative work out of the "must happen live" bucket entirely — the unlock that makes the economics work.
Elastic, but needs connectivity — a real constraint at venues like White Night's.
Used only where 1-2s latency is tolerable, not on the hard real-time path.
Two Kinesis services run in parallel, on purpose — they are not interchangeable.
Low-latency, multi-consumer fan-out feeding the live ops dashboard in real time.
Zero-ops, delivery-only landing for post-event analytics — no real-time consumption needed here.
Default to the lighter-ops option; escalate only when the workload demands it.
Stateless APIs, less ops overhead — the default posture for most of Pulse's services.
Reserved for GPU node pools and custom scheduling — used only when that's a genuine requirement, not a default.
A one-night event doesn't get a second chance if scaling lags behind the actual crowd surge.
Sized ahead of the known event-time spike, in place before doors open.
Deliberately not the default here — scale-up delay during the actual surge is the failure mode Pulse is built to avoid.
Split by durability need, not a single blanket choice.
Used where state must survive a Lambda restart — durability matters more than shaving off the last few milliseconds.
Used where raw speed matters more than durability and losing the cache on restart is acceptable.