Challenge
Restaurants usually have a PDF menu or a QR code leading to a list of items. We wanted every dish to have a short, looping video that loads quickly even on a weak signal at the table.
Video for many restaurants means heavy transfer, a risk of data leaking between venues and media delivery costs that easily get out of hand.
Approach
For video we chose a specialised CDN, because the standard plans of popular CDNs exclude this kind of use, and our own delivery network would be too expensive to maintain. We tested both options on a phone over 4G: the times were identical, so cost and terms of service decided.
Files are kept in object storage with no egress fees. Video paths are versioned and immutable, so updating a dish does not require manual cache purging.
Implementation
A worker transcodes each video to HLS in three quality levels (1080p, 720p, 480p) with two-second segments, and photos to four WebP sizes with a placeholder thumbnail. Restaurant data is isolated by a second layer in the database (RLS), checked with queries: venue A sees its own data, venue B sees nothing, and writes to other venues' data are rejected.
An early security audit found three critical problems, including open registration and the possibility of privilege escalation. All were fixed. The database has a full backup every night and continuous change logging with 30-day retention.
Results
The menu server responds in 57-77 ms, while the compared provider needed 186 ms in the same measurement. A menu with 146 photos weighs 6.0 MB instead of 16.4 MB on high-density screens and 2.7 MB on the others. 207 photos were processed in 3 minutes, with no errors.
Restore test: a temporary cluster came up in about 2 minutes with data consistent with production. The storage migration covered 1,450 objects without changing a single address.
