Cost
Scaling an event photo platform on face search: a worked model
Not a customer story — a transparent, reproducible model of the efficiency and cost of running photo delivery on a per-photo API.
Info: This is an illustrative reference model, not a named customer case study. The numbers are worked arithmetic on published per-photo rates so you can reproduce and adapt them to your own event sizes — not a claim about a specific company's results.
TL;DR
Model a mid-size event: 50,000 photos indexed, 5,000 guests each running one selfie search. At batch index $0.00062/photo and search $0.00062/search, that's about $31.00 to index + $3.10 for retrieval = roughly $34.10 in face-recognition cost for the whole event, or about $0.0068 per guest. The efficiency win isn't just price — indexing as photos arrive, isolating each event, and making retries charge-safe are what keep it reliable at scale. This breaks down the model so you can plug in your own numbers.
The scenario
- Event size: a conference/wedding-scale shoot — 50,000 photos.
- Audience: 5,000 guests, each uploading one selfie to get their gallery.
- Model: index every photo once (batch), one search per guest.
- Goal: understand the cost, the efficiency levers, and the reliability design — not just a sticker price.
The economics
| Line | Volume | Rate | Cost |
|---|---|---|---|
| Index (batch) | 50,000 photos | $0.00062/photo | $31.00 |
| Selfie retrieval | 5,000 searches | $0.00062/search | $3.10 |
| Face-recognition total | — | — | $34.10 |
| Per guest | 5,000 guests | — | $0.0068 |
At published rates, delivering personalised galleries to 5,000 guests from a 50,000-photo event costs about $34.10 in face recognition — on the order of a cent per guest. That's what makes per-guest delivery viable even for a free event.
Note: This is the face-recognition line only. Your object storage, bandwidth/CDN, delivery (WhatsApp/email), and engineering are separate and often larger — model those too before pricing your product.
Efficiency levers (beyond the unit price)
- Index as photos arrive, not in one post-event job — spreads load and gets guests their photos within minutes, the feature they actually want.
- Batch over real-time for indexing — the batch rate is the lower one; reserve real-time for the guest's own selfie search.
- Native HEIC/WebP decode — skipping a transcode stage removes compute and a failure point from the ingest hot path.
- Per-photo billing, not per face — a 30-person group shot is one billable index, so dense event photos are efficient to index.
Reliability design (what keeps it working at scale)
- Charge-safe retries — send an
Idempotency-Keyon index/batch calls so a network blip or a re-run never double-charges or double-indexes. - Per-event isolation — each event is its own collection, so one event's load or data can't affect another's searches or leak across.
- Async batch + webhook — bulk indexing runs off the guest-facing path, so a big backfill can't slow live selfie searches.
- Graceful no-match / bad-selfie handling — a blurry selfie returns a clear reason (and isn't charged for the failed engine call), so guests get a helpful retry instead of an error.
- Credit headroom — watch the
X-Credits-Remainingheader and use auto-recharge so a large event can't stall mid-index on an empty wallet.
How to adapt the model
Swap in your own numbers: multiply your photo count by the batch rate for indexing, and your expected searches (guests × searches each) by the search rate for retrieval. Add your storage, bandwidth, and delivery costs on top. The pricing calculator does the face-recognition math interactively, and the cost breakdown has more worked scenarios. To see the full platform this sits inside, read the build guide.
Plug your own event sizes into the calculator.
Open the pricing calculatorFrequently asked questions
How much does face recognition cost for an event photo platform?
Model it from per-photo rates. For a 50,000-photo event with 5,000 guests each running one selfie search, at batch index $0.00062/photo and search $0.00062/search, that's about $31.00 to index plus $3.10 for retrieval — roughly $34.10 total, or about $0.0068 per guest. Your storage, bandwidth, and delivery costs are separate. Adapt by plugging your own photo and guest counts into the same arithmetic.
Is this a real customer case study?
No — it's an illustrative reference model built from published per-photo rates, so you can reproduce and adapt the numbers to your own event sizes. It intentionally doesn't claim a specific company's results, because worked, transparent arithmetic is more useful (and more honest) than an unverifiable customer anecdote.
What makes a face-search photo platform reliable at scale?
Charge-safe retries via an Idempotency-Key so re-runs never double-charge or double-index, per-event collection isolation so events can't affect each other, asynchronous batch indexing with webhooks so bulk work doesn't slow live searches, graceful handling of bad or no-match selfies, and credit headroom (watching X-Credits-Remaining plus auto-recharge) so a large event can't stall mid-index.