Pulse is EFFOMA's edge AI and live-event platform — telemetry, edge inference, and personalized content delivery engineered for venues with no reliable internet and no second chance to get it right.
Pulse wasn't designed on a whiteboard first. It was extracted from two real events that had to work the first time.
Victorian Government engagement. Bespoke, one-off system built in 3 weeks for 30,000+ visitors, with edge inference required because the venue had no reliable internet. Load-tested at 500 simulated concurrent users, found a latency spike, and redesigned the queue overnight from synchronous to async batch processing.
The White Night result led to a referral from the Singapore Tourism Board, where EFFOMA built a hybrid content-personalization system — pre-computing ~80% of personalized content ahead of time and generating only the most dynamic 20% live.
Separate engagement, same latency discipline. Profiled and redesigned a rendering pipeline — parallel asset loading, priority queue, shared resource reuse — under 200 simulated concurrent users.
Starting in 2023, EFFOMA formalized the lessons from White Night and Singapore into Pulse — a reusable, AWS-native platform. The hybrid pre-generation approach became a template reused across 3 subsequent EFFOMA projects.
Pulse doesn't pick one tool for everything. Each layer is chosen against the specific failure mode a live event can't afford.
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 less operational surface area; escalate only when the workload genuinely 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.
Live data from a running Kinesis → Lambda → DynamoDB pipeline. It updates every 5 seconds, no refresh needed.
| Zone | Visitors | Latency | Status | Last updated |
|---|---|---|---|---|
| Connecting to live telemetry… | ||||
From formalizing White Night's lessons in 2023 to live telemetry in production today.