Foodie · nutrition intelligence at Cloudflare's edge

Flykitt's protocols tell travelers when and what to eat. A protocol that says "low inflammation, high protein" doesn't survive contact with an unfamiliar menu in another language, though. Foodie closes that gap. Point it at a restaurant anywhere in the world and it scores the menu, shortlists the dishes that match your goals, and proposes modifications when a good dish is one substitution away from being a great one.

Menus are unstructured, inconsistent, and endless. The moment of need is standing in front of one, which makes latency part of the product. The engine had to ingest hundreds of restaurants offline, then serve conversational, taste-aware suggestions online, while keeping per-request LLM cost from scaling with menu size.

Every part of Foodie runs on Cloudflare. A Worker fronts the product. Session state lives in a Durable Object per user. Concurrent lookups for the same place converge on a second Durable Object per (geohash, profile) key, so two travelers opening the same menu at the same moment do the recall, the rerank, and the LLM pass exactly once. Spatial recall is real PostGIS behind Hyperdrive, on a GiST-indexed geography column. Vectorize prefilters against the taste profile. LLM traffic egresses through AI Gateway to OpenAI, Anthropic, and Cohere, each routed to the step it is best at. The request path never leaves Cloudflare, and there is no shared connection pool to warm up.

Restaurant data enters the system three ways: on-demand when a search hits an unknown tile, on a scheduled refresh for stale tiles, and directly when a restaurant signs up. Every path lands in Queues, fans out per restaurant, and runs one Cloudflare Workflow per restaurant with durable steps. Fetch, OCR (Workers AI vision on scanned menus), extract to canonical dish records (LLM via AI Gateway), normalize and translate, geocode into a PostGIS geography column, embed each dish with bge-large on Workers AI, and commit atomically to Postgres, Vectorize, R2, and Cloudflare Images. A failed step resumes on retry; the whole restaurant never restarts.

The read path is a hierarchy that answers without doing work whenever it can. Cache API first, 30 seconds. KV next, 24-hour scoreboards keyed by geohash plus profile. Then the Search Durable Object, one instance per (geohash6, profileHash) key. If two travelers hit the same key at the same time, the second attaches to the first request's in-flight promise instead of rerunning the pipeline. On a miss, the DO runs PostGIS ST_DWithin over the GiST-indexed geography column, filters candidates through Vectorize against the taste profile, and batches LLM scoring through AI Gateway. Results write back to the DO, then KV, then Cache API, so a third caller within the TTL is a straight cache hit.

Menu photos and dish imagery flow through R2 for originals and Cloudflare Images for delivery. Signed variants for the printable scoreboard PDF, thumbnail and hero variants for the app, one origin regardless of whether the image came from a scrape, an upload, or a Workers AI generation.

What the engine actually produces, shown as-shipped: four recommendation cards spanning four cuisines, and the two product screens travelers meet first. The UI is the work of the wider Flykitt team; the pipeline that fills these cards is the scope of this case study.

The pipeline runs in production against real travelers on a paid tier. Beyond the numbers, the choice to isolate the AI workloads at Cloudflare's edge (rather than in Flykitt's AWS core) kept the rest of the platform's failure domain intact through the entire Foodie build.