The problem framed as engineering.
A national consumer promotion is not a marketing website. It is a distributed data-ingestion system with strong correctness requirements: every submission must be deduplicated, every submission must be auditable, every prize draw must be defensible under public scrutiny. The failure mode is not slow — it is a contested winner, a duplicate entry, or a lost submission during a traffic burst.
The engineering discipline here is data integrity under bursty load with three heterogeneous clients writing into the same domain. A responsive consumer web reaches submissions from any device at any time. An in-store tablet reaches submissions from supermarket floors where the operator has no IT staff and the session must self-recover from abandonment. A brand operations console reaches submissions from moderators who must make binding decisions under time pressure.
Symloop's position from day one: one domain model, one write path, one audit log — three render targets, each engineered for the physical reality of where it runs.
One system. Three render targets.
Consumer entry surface — a responsive single-page application with form-factor-specific layouts. The design principle: responsive CSS stretches the same UI across breakpoints, which is the wrong architecture when touch targets, input modality, and viewport context differ. We treat desktop, tablet, and mobile as three distinct render targets sharing the same form model, input validation, and submission pipeline — swapping the layout tree at runtime based on device class and orientation.
In-store tablet surface — a kiosk-hardened client engineered for unattended operation on supermarket floors. Self-recovering session state after idle timeout, attract-mode that prevents dead-screen failure, touch targets sized for gloved or hurried consumers, and a narrow deployment target that eliminates the class of bugs that come from running general-purpose software in a kiosk context.
Operations console — a brand-side console with strict separation between ingestion and review. The team reviewing entries never shares a code path with the team submitting them. Role-scoped access, immutable audit log per decision, and an export pipeline that produces a prize-draw manifest with a defensible provenance trail — so the draw itself is verifiable end-to-end.
Burst-aware, correctness-first, audit-complete.
Write-path isolation. Consumer ingestion and operator review run on separate read/write planes. When a TV spot spikes consumer writes by an order of magnitude, the review console stays responsive because it reads from a path that does not contend with the ingestion firehose.
Deterministic deduplication at the write boundary. Duplicate detection runs at submission time, not in batch post-facto. Perceptual hashing on receipt imagery, stable identity hashing across submission fields, and idempotent write keys so a retry never creates a ghost entry.
Immutable audit log. Every state transition — submission, validation flag, moderator decision, export event — is appended to an audit log that is readable by the operations team and not mutable by anyone, including engineers. This is how a prize draw remains defensible.
Burst-aware static delivery. The consumer surface is delivered as static assets from an edge network so a TV-driven traffic burst never touches origin infrastructure for the first paint. Dynamic state — submissions, validation — scales horizontally on managed primitives so we pay for capacity at the second, not the hour.
What made this hard, and how we resolved it.
- 01
Cross-surface consistency without code duplication
Three render targets must behave identically on the dimensions consumers experience — same form semantics, same validation errors, same receipt-submission flow — while differing on the dimensions the physical surface demands. The failure mode is divergence: the consumer web rejects an input the kiosk accepts, a moderator sees a receipt format the consumer never submitted. We kept the domain model singular and isolated the render surfaces from domain logic so no rule can exist in one client and not the others.
- 02
Adversarial input on an open endpoint
The consumer endpoint is public by definition. Duplicate submissions, machine-generated entries, and image reuse are not edge cases — they are the baseline. The engineering stance is defensive from the first commit: perceptual hashing on imagery, identity hashing across submission fields, rate limits anchored to multiple signals rather than IP alone, and a moderation queue with an explicit budget for manual review. The goal is not zero fraud — it is a defensible rate where human review is economically bounded.
- 03
Kiosk deployment without field engineers
The kiosks run in retail environments where we have no staff. A consumer may abandon the screen mid-entry, pull the power, or block the screen. The software has to recover from every one of these states to a known-good attract mode within seconds. We treat every kiosk boot as if the last session crashed — because statistically, some of them did.
- 04
Operator-side review under time pressure
A prize draw has a deadline. The operations team reviews submissions on that deadline. If the review console is sluggish because the ingestion path is saturated, the draw slips and the campaign degrades. We separated the ingestion and review planes at the infrastructure level so a consumer traffic spike cannot make a moderator wait.
What ran in production, and what was verifiable.
- 01
Three render surfaces operational on launch day against the same domain model, with no behavior divergence observable between them.
- 02
Moderation console produced an auditable prize-draw manifest with complete per-submission provenance — submission time, dedupe state, moderator decision, export event — readable by the brand team without engineer involvement.
- 03
Burst load absorbed without origin-server intervention. Static-first delivery meant the first paint is never a contended resource, and the dynamic write path scaled on managed primitives.
- 04
Kiosks self-recovered from abandonment without field support. The deployment model assumes the physical environment is hostile and engineers accordingly.
What operators and technical buyers ask us about this project.
01Why treat desktop, tablet, and kiosk as separate render targets instead of one responsive codebase?+
Because responsive CSS encodes the assumption that the same UI is correct across devices. It is not. A kiosk in a retail aisle needs session timeouts, attract mode, and touch targets that have no analogue on a desktop browser. We keep the domain model singular and the render targets distinct — the duplication is small, the divergence risk is smaller, and each target is fit-for-purpose rather than a compromise.
02How is the prize-draw result defensible under scrutiny?+
Every state transition — submission, validation flag, moderation decision, export event — is appended to an immutable audit log keyed on submission identity. The draw manifest is generated from this log, not from the live database. If a submission is contested, the provenance is in the log and not reconstructible after the fact. This is how we design for events where the output has to survive public examination.
03How do you handle adversarial input without blocking legitimate consumers?+
Duplicate detection is deterministic and runs at the write boundary. Rate-limiting is anchored to multiple signals — device fingerprint, submission identity hash, temporal pattern — not IP alone, because mobile networks translate millions of users through a small number of IPs. Moderation is reserved for the small percentage that automated checks flag, with an explicit budget so human review is economically bounded.
04What is the engineering cost of burst traffic absorption?+
Near-zero when the architecture is correct. Static-first delivery from an edge network makes the first paint free. Dynamic writes scale on managed primitives that price by the second. The cost model is a function of the submission volume, not the traffic surge — which is exactly how bursty consumer events should price.
05Does the same architecture transfer to other consumer-brand events?+
Yes. The engineering shape — three-surface ingestion, bursty write path, audit-complete moderation, defensible output event — repeats across on-pack promotions, scan-to-redeem mechanics, loyalty activations, and retail-tied contests. The domain logic changes. The architecture does not.
