How Kamero moved event photo face search off AWS Rekognition

Where Kamero started

Kamero does one thing for guests: after an event, a guest uploads a selfie and gets every photo they appear in. It originally did that face matching with AWS Rekognition.

Four problems with that set-up pushed the move:

• Per-call cost at scale. Every indexed photo and every guest search was a Rekognition charge.
• No control over the face detector or the match threshold, so Kamero could not tune for its own photos.
• Weak recall on small faces in crowd photos, which is where event photos are densest.
• Lock-in to a single provider's API and pricing.

How the move was done

SightRadar began as Kamero's in-house face engine and was then turned into a multi-tenant engine, with Kamero as tenant number one. The move happened in stages, and each stage had a measured check before the next one started.

• Index the whole back catalogue. Kamero's full photo corpus was indexed into SightRadar, reaching more than 98% coverage before search was switched over.
• Fix small faces first. The face detector was changed to scan each photo at several scales, to recover the small faces in crowd shots that a single-scale pass missed.
• Never auto-confirm on rank alone. Matches above a high threshold show up automatically. A band below it asks the guest to tap to confirm. The top-ranked result is never shown as certain only because it ranked first, which guards against strangers' photos landing in a guest's gallery.
• Shadow-compare, then flip. Before cutover, 200 probe searches ran on both SightRadar's original search path and its multi-tenant path. They returned 100% identical results, lost 0 matches and differed by a 0.0 score. Only then was search switched over, starting with the priority fleet.
• Merge into one corpus. Faces that had been written to a second store during the transition (518,606 of them) were merged into the shared corpus. A sample of 1,000 out of 1,000 was verified as present afterwards.

Where it runs today

Kamero's face search now runs on the SightRadar engine, through the same multi-tenant search path and the same shared corpus that serve every SightRadar API customer. Each tenant's faces are kept apart by namespace.

Bulk indexing of event uploads runs on a batch fleet that scales to zero between bursts. Guest searches run on the real-time path. AWS Rekognition is kept only as an offline comparison baseline until it is decommissioned.

What this means if you are evaluating SightRadar

Every SightRadar API customer uses the same engine, corpus architecture and search path that serve Kamero's production traffic. If you are moving from AWS Rekognition yourself, the official Python shim keeps Rekognition-shaped code working, and the migration guide covers the method mapping and a step-by-step runbook.

Do not copy Kamero's thresholds. They were tuned on Kamero's own event photos. Derive yours from labelled pairs of your own photos, the same way Kamero did.