Picture two sellers on the same marketplace, both selling the same style of backpack. Seller A spends a weekend photographing their own backpack against a clean white background, in good lighting, from six different angles. A week later, Seller B lists an identical-looking backpack — using the exact same six photos, just slightly cropped and with the brightness nudged up. Seller B never took a single photo. They simply right-clicked, saved, and re-uploaded Seller A’s work as their own.

This is image theft in a marketplace context, and it is a bigger problem than it might sound. Good product photography is expensive and time-consuming — professional listing photos can cost a seller real money in photography, staging, and editing time. When a competitor copies those photos for free, it erodes the original seller’s competitive advantage, can mislead customers about which seller they’re actually buying from, and — in cases where the copied images contain the original seller’s watermark or storefront branding — creates outright customer confusion and trust damage across the whole marketplace.

The technology for detecting duplicate or near-duplicate images has a long history. In the early 2000s, perceptual hashing algorithms (like pHash and dHash) let engineers compute a short “fingerprint” of an image — two images that look visually similar produce fingerprints that are close to each other, even if the underlying bytes are completely different. This is how services like TinEye built reverse-image search in the mid-2000s, and it’s still a fast, cheap first line of defense today.

The second wave arrived with deep learning. Convolutional neural networks (CNNs), and later vision-transformer-based models like OpenAI’s CLIP, learned to produce rich numerical embeddings — vectors of a few hundred to a couple thousand numbers — that capture the actual visual and semantic content of an image. Two photos of the same backpack, even if one is rotated, cropped, filtered, or has a watermark stamped over it, produce embeddings that sit close together in that vector space. This is what modern stolen-image detection is really built on: perceptual hashing catches the easy, near-identical cases cheaply, and embedding-based similarity search catches the harder, transformed cases.

A Short History of Duplicate-Image Detection

Before diving into architecture, let’s be precise about the business problem, the engineering constraints, and the goals that shape every design choice downstream.

2.1 The Business Problem

Marketplaces with millions of sellers see an enormous, continuous stream of new listing images — new listings, re-listings, and photo updates on existing listings, all day, every day. A meaningful percentage of these images are not original: they are copied from another seller on the same marketplace, scraped from a competitor’s site, or lifted from a brand’s official catalog without a reseller agreement. Left unchecked, this: (1) discourages honest sellers from investing in quality photography, since their work gets copied for free, (2) creates listings where the photo doesn’t match the actual item being shipped, driving returns and complaints, and (3) can expose the marketplace itself to copyright-infringement liability if it’s notified and doesn’t act.

2.2 The Engineering Problem

1. Scale — this tutorial is scoped explicitly for a peak load of roughly one million image-check requests per minute (~16,700/sec sustained, with bursts higher), driven by bulk catalog uploads, marketing-driven listing pushes, and seasonal onboarding waves.
2. Near-duplicate, not just exact-duplicate, detection — thieves crop, rotate, mirror, recolor, add watermarks, or resize images specifically to evade naive duplicate checks.
3. Enormous comparison space — a new image must be checked against a corpus of potentially billions of existing listing images, which rules out any naive “compare against everything” approach.
4. Precision over recall for enforcement actions — falsely flagging an honest seller’s original photo as “stolen” is reputationally and legally costly, so the system must be conservative about automatic enforcement and route ambiguous cases to human review.
5. Latency tolerance is looser than a live chat — unlike a live chatbot, most image checks do not need to block the seller’s upload flow in real time; a few seconds to low minutes of asynchronous processing is generally acceptable, which materially changes the architecture.
6. Legitimate re-use must be allowed — brands, authorized resellers, and marketplace-provided stock photos are copied “legitimately” all the time; the system must distinguish unauthorized copying between independent sellers from authorized shared imagery.

2.3 Goals of This Design

• Detect near-duplicate and transformed-duplicate listing images with high precision.
• Sustain a peak ingest rate of roughly 1,000,000 image events per minute.
• Keep automated-enforcement false-positive rate extremely low; route uncertain matches to human review.
• Return an asynchronous verdict within a target of under 2 minutes at P95 for the large majority of images, with a fast-path option for pre-publish checks on a small, latency-sensitive subset.
• Support seller appeals and maintain a full audit trail for every enforcement action.

Explicit functional, non-functional, and scoping requirements — plus a capacity walkthrough that grounds every downstream architectural choice in concrete numbers rather than vibes.

3.1 Functional Requirements

• Ingest every new or updated listing image across the marketplace.
• Compute a similarity fingerprint for each image and search it against a large corpus of previously seen images.
• Determine, for high-confidence matches, which listing is the likely original (based on first-seen timestamp, seller trust score, and metadata) and which is the likely copy.
• Apply graduated enforcement: warn, require photo replacement, suppress the listing, or escalate to a trust-and-safety review queue, depending on confidence and severity.
• Allow sellers to appeal a flag, with a human-reviewable audit trail of the evidence (matched images, similarity score, timestamps).
• Support a “trusted source” allow-list (official brand catalogs, marketplace-provided stock imagery) that must not trigger theft flags between authorized users of the same source images.

3.2 Non-Functional Requirements

3.3 Explicit Non-Goals

• We are not designing general content moderation (nudity, prohibited items) — only visual-similarity-based image-theft detection, though the ingestion pipeline could feed both.
• We are not building the underlying deep-learning model training pipeline from scratch — we assume an existing or off-the-shelf embedding model (e.g., a CLIP-style vision encoder) is available and treat model training/retraining as a supporting, offline concern.
• We do not attempt to detect theft of product descriptions or text — images only.

3.4 Capacity Estimation Walkthrough

The prompt specifies a peak of roughly one million requests per minute, so let’s turn that into concrete infrastructure numbers, the way an interviewer expects.

The GPU math is the number worth dwelling on in an interview: at this scale, embedding computation is almost certainly the most expensive part of the pipeline, which directly motivates two design decisions covered later — batching inference requests instead of processing one image at a time, and using a cheap perceptual-hash pre-filter to avoid running the expensive embedding model on images that are obviously not near-duplicates of anything (e.g., a small hash-based bucket check before the GPU stage).

3.5 Cross-Border and Cross-Marketplace Considerations

Large marketplaces typically operate as a single logical platform spanning many countries and, in some corporate structures, several branded sub-marketplaces sharing back-end infrastructure. This raises a scoping question worth surfacing explicitly in an interview: should the vector index be one single global corpus, or partitioned per region/sub-marketplace? A single global index catches theft that crosses borders — a seller in one country copying photos from a seller in another — but at the cost of a larger index to search per query and potential legal complexity if certain regions have different data-residency requirements for where image data and metadata can be stored and processed. A partitioned-per-region index is cheaper to query and simpler for data-residency compliance, but misses cross-region theft entirely. This design defaults to a hybrid similar to the hot/cold split from Chapter 17: maintain per-region indexes for the fast, primary detection path to satisfy both performance and data-residency needs, plus a lower-priority, asynchronous cross-region reconciliation job that periodically checks a sample of new embeddings against other regions’ indexes to catch cross-border copying, accepting a longer detection latency for that specific case in exchange for not paying the cost of a single unified global index on every single upload.

A queue-driven, two-stage detection pipeline — every custom service behind its own load balancer, the API Gateway as the single authenticated entry point, and asynchronous fan-out from the Kafka hop onward.

4.1 High-Level Component List

4.2 Architecture Diagram

4.3 Component Deep-Dive

Load Balancer & API Gateway

Same role as in any large system: the L7 Load Balancer terminates TLS and spreads incoming upload traffic across API Gateway instances using health-check-aware routing; the API Gateway authenticates the seller, applies per-seller rate limits (important here specifically to blunt abusive bulk-upload bots), and routes validated requests to the Listing Service.

Object Storage

Raw uploaded images are written to durable, cheap object storage (S3-style) immediately on upload — this is the permanent source of the actual image bytes. Every downstream service works with a reference (URL/key) to this stored object rather than passing large binary blobs through the queue, keeping Kafka messages small and fast.

Ingestion Queue (Kafka)

This is the shock absorber of the whole system. The Listing Service publishes a lightweight event (listing ID, image key, seller ID, timestamp) to a partitioned Kafka topic the moment an image is stored — partitioned by, for example, a hash of seller ID, so a single seller’s bulk upload can’t create a hot partition that starves everyone else. Consumers (the Pre-Filter Service) read from this topic at whatever rate their capacity allows, and a temporary backlog during a burst is completely normal and safe — the topic just holds more unprocessed messages until capacity catches up.

Pre-Filter Service — the Cheap First Pass

Given the GPU cost analysis in Chapter 3, running the expensive embedding model on every single image is wasteful when a huge fraction of new images are obviously unique (a genuinely original photo of a genuinely unique product). The Pre-Filter Service computes a cheap perceptual hash (pHash/dHash) for the incoming image and checks it against a Redis-backed index of recently-seen hash buckets. If there’s no bucket collision at all — meaning nothing even loosely resembles this image at the coarse hash level — many designs skip straight to indexing it as a new, presumed-original embedding without the full expensive similarity search, or route it through at lower priority. If there is a bucket collision, the image is forwarded to the full embedding pipeline for a much more precise check.

Embedding Service

This is the GPU-backed heart of the system. It runs a pretrained vision embedding model (a CLIP-style encoder or a custom-trained CNN) over each image, producing a fixed-length numeric vector that captures visual content in a way that’s robust to cropping, rotation, color adjustment, and watermarking. Critically, this service processes images in batches (e.g., 64 images per GPU forward pass) rather than one at a time, because batched inference is dramatically more GPU-efficient — this is the single biggest lever for hitting the throughput numbers from Chapter 3 affordably.

Vector Index / ANN Search Service

With a corpus of billions of images, you cannot compare a new embedding against every existing one — that’s an O(n) operation per lookup that would collapse at this scale. Instead, this service uses an Approximate Nearest Neighbor (ANN) index (technologies like FAISS, HNSW-based indexes, or a managed vector database such as Milvus) that can find the closest matching vectors in roughly logarithmic or sub-linear time, trading a small amount of accuracy for a massive speed gain. The index is sharded across many nodes, each behind its own load balancer, since a multi-terabyte index cannot live on a single machine.

Match Scoring Service

A raw similarity score alone isn’t a verdict. This service combines the ANN search’s top candidate matches with metadata from the Metadata Store — which listing’s image was uploaded first, whether the two sellers are linked to the same brand/allow-listed source, the historical trust score of each seller — to compute a final confidence level and decide the likely “original” versus “copy.” This is also where the similarity threshold tuning discussed in Chapter 8 happens.

Trusted-Source Allow-List Service

Brands often authorize multiple resellers to use the same official product photos, and the marketplace itself sometimes supplies stock imagery sellers are permitted to reuse. This service maintains a registry of such authorized shared-image relationships and is checked before any enforcement action fires, preventing the system from punishing entirely legitimate, authorized image reuse.

Enforcement, Review, Appeals & Notification Services

High-confidence, high-severity matches can trigger graduated automated enforcement (warning, requiring a photo swap, or listing suppression). Anything below the automation confidence bar — and, by policy, a sample of automated actions too, for ongoing quality auditing — is routed to a human Trust & Safety review queue. Sellers can dispute a verdict through the Appeals Service, which surfaces the full evidence trail (matched image, similarity score, timestamps) to a reviewer. The Notification Service informs sellers of outcomes at every stage.

Let’s trace one image, end to end, through the pipeline.

5.1 Sequence Diagram

5.2 Handling Transformed Copies

The system’s robustness to cropping, rotation, mirroring, recoloring, and watermarking comes almost entirely from the choice of embedding model, not from explicit rule-writing. A well-trained vision embedding model learns that a cropped version of an image and the full image are semantically “close” in vector space, without anyone hand-coding a “check for crops” rule. This is worth stating clearly in an interview: you are not writing per-transformation detection logic; you are relying on a model whose training objective specifically rewards being invariant to exactly these kinds of transformations, and you validate that invariance empirically via the evaluation suite in Chapter 17.

5.3 Multi-Image Listings and Category-Aware Bucketing

Real listings rarely have just one photo — a typical listing might include four to eight images (front, back, detail shots, in-use shots, packaging). This has two practical consequences for the design. First, the unit of theft detection is really the individual image, not the listing, since a thief might copy only some of a victim’s photos and mix in a couple of their own — the Match Scoring Service therefore aggregates per-image verdicts up to a listing-level severity score (e.g., “3 of 6 images matched an existing listing at high confidence”) rather than treating any single match as automatically conclusive about the whole listing. Second, the hash-bucket and ANN index can optionally be partitioned or pre-filtered by product category (electronics, apparel, home goods) inferred from the listing metadata, which both shrinks the effective search space per query — improving latency and reducing GPU/index load — and reduces spurious cross-category collisions, since a phone case and a couch cushion are extremely unlikely to be genuine theft candidates of each other even if their coarse visual hash happens to overlap.

5.4 Re-Scoring Over Time

Theft is not always detected at the moment of upload — sometimes the original image is added to the corpus after the copy, simply because of the order sellers happened to upload in, or because the corpus itself is still being backfilled during initial rollout. To handle this, the system periodically re-runs a lower-priority batch job that re-queries recently added embeddings against the index again after some delay (for example, 24 hours and again at 7 days), catching cases where the “true original” was indexed slightly later than its copy. This re-scoring job runs at low priority in the same GPU pool, filling otherwise-idle batch capacity rather than competing with fresh, latency-sensitive uploads.

The write path (new image ingestion) and the read path (buyer viewing a listing) are deliberately independent, so a slow or degraded detection pipeline never touches the buyer experience.

6.1 Write Path (New Image Ingestion)

Seller → Load Balancer → API Gateway → Listing Service → Object Storage + Kafka event → Pre-Filter → Embedding → Vector Index write + ANN search → Match Scoring → Enforcement. This entire chain is asynchronous and queue-driven from the Kafka hop onward, which is what lets it absorb bursty, bulk-upload traffic without needing to instantly scale to peak capacity.

6.2 Read Path (Buyer Viewing a Listing)

Completely separate from the theft-detection pipeline: buyers view listing images served directly from Object Storage via the CDN, unaffected by whatever is happening in the detection pipeline, except that a suppressed listing (post-enforcement) is simply removed from what the Listing Service serves to buyers.

6.3 Data Lifecycle

Every architectural choice buys you something and costs you something. Making those trade-offs explicit is what turns “we picked ANN search” into a defensible engineering decision.

7.1 Key Trade-off: Exact ANN vs. Approximate ANN

Given the scale constraints established in Chapter 3, approximate search isn’t just a nice-to-have optimization, it’s a hard requirement — brute-force comparison against a multi-billion-image corpus at this query rate is not achievable with any reasonable amount of hardware.

7.2 Key Trade-off: Automation Aggressiveness

A more aggressive similarity threshold catches more theft (higher recall) but increases false accusations (lower precision); a conservative threshold protects honest sellers but lets more theft through. This design resolves the tension by using automation only above a very high-confidence threshold and routing the large “maybe” middle ground to human review rather than trying to force a fully automated binary decision.

7.3 The Economics Behind the Precision-First Bias

It is worth spelling out explicitly why this design consistently favors precision over recall, since it is a recurring theme across nearly every threshold decision described in this tutorial. The cost of a missed theft case is bounded and recoverable: the victim seller can still report it manually, it can be caught later by the periodic re-scoring job in Chapter 5, or it can simply persist a while longer as one bad actor among many. The cost of a false accusation is comparatively unbounded and much harder to undo: an honest seller’s original, hard-earned photography gets suppressed or flagged, their trust in the platform erodes, and if it happens systematically it becomes a public trust and potentially legal liability for the marketplace as a whole. This asymmetry — bounded cost for a false negative versus outsized cost for a false positive — is the same reasoning that justifies keeping human review and appeals as permanent, load-bearing parts of the architecture rather than temporary scaffolding to be automated away once the model is “good enough.”

At million-per-minute scale, aggregate throughput — not per-request latency — is the binding constraint. That single observation is what justifies the queue-driven, batched-inference shape of this entire architecture.

8.1 Where Time Actually Goes

Notice that none of these per-stage numbers is the bottleneck on its own — the real constraint at a million requests per minute is aggregate throughput, not any single request’s latency, which is exactly why the asynchronous, queue-buffered design from Chapter 4 is the right shape for this problem, unlike a chat system where per-request latency was the binding constraint.

8.2 Scaling Strategies

• Horizontal scaling of Pre-Filter, Match Scoring, and Enforcement services behind their own load balancers, auto-scaling on Kafka consumer lag rather than just CPU.
• GPU autoscaling for the Embedding Service, scaling the node pool based on queue depth, with request batching maximizing throughput per GPU.
• Sharded ANN index — partition the vector index by a scheme such as a coarse pre-clustering (e.g., product category or a hash of the vector itself), so any single query only needs to search a subset of shards, and the index can grow by adding shards rather than resizing a single monolithic index.
• Kafka partitioning by seller ID hash to parallelize consumption while avoiding hot partitions from any single bulk-uploading seller.
• Two-stage filtering (cheap hash, then expensive embedding) is itself a scalability strategy — it keeps the most expensive resource (GPU time) proportional to genuinely ambiguous cases rather than total volume.

8.3 Handling Burst Traffic (Bulk Catalog Uploads)

When a large seller or a marketplace onboarding wave pushes tens of thousands of images at once, Kafka’s backlog absorbs the spike without requiring instant capacity. Consumer groups scale out to drain the backlog over the following minutes, and a monitored SLA (e.g., “95% of images get a verdict within 2 minutes of upload, even under burst”) is enforced by autoscaling policy rather than by trying to provision permanently for peak.

8.4 Cost Optimization

At this scale, GPU-hours for the Embedding Service are almost certainly the dominant infrastructure cost, so it is worth listing the concrete levers beyond the two-stage filtering pattern already covered. Dynamic batching with a small wait window (e.g., accumulate up to 64 images or 20 milliseconds, whichever comes first) maximizes GPU utilization without meaningfully hurting the async latency budget. Choosing a smaller, distilled embedding model for the initial candidate search and only falling back to a larger, more accurate model to confirm borderline matches (a coarse-then-fine cascade, mirroring the hash-then-embedding cascade at a different layer) further cuts average GPU cost per image. Spot/preemptible GPU instances can handle the low-priority re-scoring batch job from Chapter 5, since that workload tolerates interruption far better than the fresh-upload path does. Finally, compressing stored embeddings (e.g., product quantization) trades a small amount of search precision for a large reduction in vector index memory and storage footprint, which matters directly given the multi-terabyte index size estimated in Chapter 3.

8.5 Index Maintenance at Scale

An ANN index that only ever grows will eventually need active maintenance, not just more shards. Periodic index compaction removes embeddings for listings that have been deleted or permanently suppressed, keeping the search space focused on currently-relevant images rather than accumulating dead weight indefinitely. Re-indexing campaigns are also needed whenever the embedding model itself is upgraded to a new version, since old and new embeddings are not directly comparable in the same vector space — this is typically handled by running both the old and new index in parallel during a migration window, with new uploads written to both and a background job backfilling historical images into the new index, before finally cutting reads over and retiring the old index.

Kafka is the durability spine: because ingestion is queue-based, a full outage of the vision pipeline never loses events — they just queue up and drain when capacity comes back.

Two distinct authorization boundaries, active defense against adversarial evasion, and a principled defense-in-depth stack rather than a single “clever check.”

10.1 Authentication & Authorization

Only the authenticated owner of a listing can upload images to it, verified at the API Gateway by the marketplace’s existing identity system. Beyond upload authorization, this system introduces a second, distinct concern: enforcement authorization — the Enforcement Service must only take action on listings after independently confirming, via the Metadata Store, that the match scoring pipeline’s verdict is well-formed and the target listing genuinely exists and is currently active, protecting against a corrupted or replayed event triggering an erroneous suppression.

10.2 Preventing Evasion

Because sellers who steal images have a direct incentive to evade detection, the system must anticipate adversarial behavior: minor pixel-level perturbations designed specifically to shift an embedding just past the similarity threshold, splitting one stolen image into multiple slightly-different crops uploaded separately, or laundering an image through several unrelated accounts before using it. Mitigations include training/fine-tuning the embedding model with adversarially perturbed examples so it remains robust to small deliberate perturbations, cross-account pattern detection (the same suspicious image appearing across many new accounts in a short window), and periodically re-scoring older images against newly added corpus entries rather than only checking at upload time.

10.3 Data Protection & Fairness

• Enforcement decisions and their evidence are logged immutably for audit and legal defensibility.
• Seller PII is not required for the core similarity pipeline — the Embedding and Vector Index services operate on image content and listing IDs, not personal seller data, minimizing exposure.
• Appeals data and reviewer decisions are access-controlled, since they can include sensitive account-standing information.

10.4 Defense in Depth Summary

As with any system that combines a probabilistic component (the similarity model) with real-world consequences (enforcement actions against a seller’s livelihood), no single layer here is assumed sufficient on its own. Upload-time authentication confirms who is allowed to add images to a given listing. The Trusted-Source Allow-List gates out authorized shared imagery before it ever reaches an enforcement decision. Confidence thresholds separate automated action from human-reviewed action based on how certain the evidence actually is. The Appeals Service provides a recourse path even after an automated action fires. And continuous sampled precision audits (Chapter 11) catch systemic drift that no single decision-time check could catch on its own. Removing any one of these layers should degrade the system’s fairness margin, not eliminate it — that redundancy, not any single clever check, is what makes large-scale automated enforcement defensible.

Two very different metric categories matter: throughput/health of the pipeline and quality of its detection decisions. Conflating them causes real precision regressions to hide behind cheerful green infrastructure dashboards.

11.1 System-Level Metrics

11.2 Model/Detection-Specific Metrics

11.3 Tracing

Distributed tracing stitches a single trace ID from the original Kafka event through Pre-Filter, Embedding, Vector Index, and Match Scoring, so engineers can quickly answer “why did this specific image take four minutes to get a verdict” by seeing exactly which stage the time was spent in.

11.4 Alerting Philosophy

Two very different categories of alert matter here, and conflating them leads to either alert fatigue or dangerously slow response. Infrastructure alerts — Kafka lag growing unboundedly, GPU pool exhaustion, ANN shard unavailability — should page on-call engineers quickly, the same as any other production system, because they threaten the throughput SLA directly. Quality alerts — a drop in sampled precision, a spike in successful appeals, an unusual concentration of flags against a specific seller cohort that might indicate a bug rather than genuine theft — should route to a trust-and-safety or ML-quality on-call rotation rather than pure infrastructure engineers, since diagnosing them requires domain judgment about detection behavior, not just system health. Blurring these two categories into one generic alert queue tends to mean quality regressions get deprioritized behind infrastructure noise, even though a silent precision collapse can do more lasting damage to seller trust than a short infrastructure outage.

CPU-bound and GPU-bound service pools scale independently because their cost economics are fundamentally different — and every model deploy is treated with the same seriousness as a code deploy.

• Containerized services (Docker) for all CPU-bound components (Pre-Filter, Match Scoring, Enforcement, Appeals), orchestrated via Kubernetes for scheduling and rolling updates.
• Dedicated GPU node pools for the Embedding Service, separately autoscaled from the CPU-bound services, since GPU nodes are far more expensive and have different scaling economics (batch efficiency matters more than raw instance count).
• Multi-region Kafka and vector index for large global marketplaces, with regional processing where possible to reduce cross-region data transfer of image bytes, while keeping a global view for cross-region theft detection where sellers or thieves operate across regions.
• Canary deployments for new embedding model versions — route a small percentage of the pipeline’s traffic to the new model, compare precision/recall against the golden set and against the current production model before full rollout.
• Infrastructure as Code for reproducible environments, especially important given the complexity of GPU node pools and sharded index configuration.

Different data shapes want different storage engines. Forcing all of this into one general-purpose relational database would collapse under the ANN query pattern well before the throughput bar was ever a concern.

13.1 Why the Vector Index Is a Distinct Data Store

A relational database is the wrong tool for “find the K most similar 512-dimensional vectors out of five billion” — that’s not a query relational indexes (B-trees) are built for. This is why a dedicated ANN vector index (FAISS-based, HNSW-based, or a managed vector database) exists as its own specialized data store, separate from the relational Metadata Store that holds ownership and timestamp information. The two are joined at query time by the Match Scoring Service, not merged into one system.

13.2 What We Store Where

13.3 Load Balancing Strategy

As with the general pattern, every custom service sits behind its own load balancer, typically implemented via a service mesh inside Kubernetes for the CPU-bound services. The Vector Index Service is a special case: its “load balancing” is really a two-level routing problem — first routing a query to the correct shard(s) based on the index’s partitioning scheme, then, within a shard, load-balancing across that shard’s replica nodes for read availability and throughput.

13.4 Redis Hash Bucket Schema

The upload path is synchronous (sellers need immediate listing confirmation); everything past the Kafka publish is asynchronous and event-driven. A narrow, opt-in fast-path exists for pre-publish checks.

14.1 Example Kafka Event Schema

{
  "event_type"         : "image_uploaded",
  "listing_id"         : "L-990214",
  "image_id"           : "IMG-7743310",
  "seller_id"          : "S-55210",
  "object_storage_key" : "listings/990214/img-7743310.jpg",
  "uploaded_at"        : "2026-08-03T09:14:02Z"
}

14.2 Java: Pre-Filter Service Bucket Check

A simplified but realistic sketch of the cheap first-pass filter that decides whether an image needs the expensive embedding stage.

public class PreFilterService {

    private final PerceptualHasher hasher;
    private final RedisHashBucketStore bucketStore;
    private final EmbeddingQueueClient embeddingQueue;

    public PreFilterService(PerceptualHasher hasher,
                            RedisHashBucketStore bucketStore,
                            EmbeddingQueueClient embeddingQueue) {
        this.hasher = hasher;
        this.bucketStore = bucketStore;
        this.embeddingQueue = embeddingQueue;
    }

    public void process(ImageUploadedEvent event, byte[] imageBytes) {

        String hash = hasher.computePerceptualHash(imageBytes);
        // coarse prefix keeps the bucket small enough to look up in Redis in ~1ms
        String bucketKey = hash.substring(0, 10);

        Set<String> collidingImageIds = bucketStore.getBucket(bucketKey);

        // always record this image so future uploads can compare against it
        bucketStore.addToBucket(bucketKey, event.getImageId());

        if (collidingImageIds.isEmpty()) {
            // no coarse collision -- likely a genuinely unique image
            embeddingQueue.enqueueLowPriority(event);
            return;
        }

        // coarse collision found -- worth the precise, expensive check
        embeddingQueue.enqueueHighPriority(event);
    }
}

14.3 Java: Match Scoring Decision Logic

public class MatchScoringService {

    private static final double AUTO_ENFORCE_THRESHOLD = 0.97;
    private static final double HUMAN_REVIEW_THRESHOLD = 0.85;

    private final MetadataStoreClient metadataStore;
    private final TrustedSourceAllowList allowList;

    public Verdict scoreMatch(ImageUploadedEvent newImage,
                              List<AnnCandidate> candidates) {

        for (AnnCandidate c : candidates) {

            if (allowList.isAuthorizedPair(newImage.getSellerId(), c.getSellerId())) {
                continue; // authorized shared imagery, never flag
            }

            ListingMeta originalMeta = metadataStore.getListingMeta(c.getListingId());

            if (c.getSimilarity() >= AUTO_ENFORCE_THRESHOLD
                    && originalMeta.getFirstSeenAt().isBefore(newImage.getUploadedAt())) {
                return Verdict.autoEnforce(newImage, c);
            }

            if (c.getSimilarity() >= HUMAN_REVIEW_THRESHOLD) {
                return Verdict.routeToHumanReview(newImage, c);
            }
        }

        return Verdict.clear(newImage);
    }
}

14.4 Synchronous vs. Asynchronous APIs in This Design

The upload path (Seller to Listing Service) is a synchronous REST call, because the seller needs immediate confirmation their listing was created. Everything from the Kafka publish onward is asynchronous and event-driven — the seller does not wait for a theft verdict to complete their listing flow. A narrow “fast-path” synchronous API can optionally be exposed for a small subset of pre-publish checks (e.g., a premium seller tool that checks likely-theft before submission), implemented as a lightweight, latency-bounded call directly against the Pre-Filter and a size-limited ANN query, separate from the main high-throughput asynchronous pipeline.

The design leans on a familiar set of large-scale patterns — and it deliberately avoids a matching set of anti-patterns that would silently destroy either its precision or its economics.

15.1 Patterns Used

15.2 Anti-Patterns to Avoid

Detection confidence and enforcement action are separate concerns; the trusted-source allow-list is a hard gate, not a nice-to-have; and thieves adapt, so thresholds are living configuration rather than one-time constants.

16.3 Repeat-Offender Scoring

A single flagged image, on its own, is a relatively weak signal for severe enforcement — even honest sellers occasionally trigger a borderline match. A much stronger signal is a pattern over time: a seller account accumulating multiple independent high-confidence matches across different listings and different victim sellers. Best practice is to maintain a rolling seller-level trust/violation score, separate from any single image’s verdict, and let that score modulate both the automation threshold (a seller with a clean history gets more benefit of the doubt on a borderline match) and the severity of enforcement action (a first-time borderline match might warrant only a warning and a request to replace the photo, while a fifth confirmed violation from the same account might warrant listing suppression or account-level review). This mirrors how many real trust-and-safety systems are designed: individual signals are noisy, but accumulated account-level patterns are much more reliable, and building that accumulation into the design from the start avoids treating every case as an isolated, context-free decision.

Concrete production analogues, a first-class evaluation methodology, and a plain-English glossary of the vocabulary this design leans on.

17.1 Industry Examples

17.2 Choosing an ANN Index Implementation

Interviewers sometimes push on this specific choice, so it’s worth having a concrete opinion rather than treating “vector database” as a black box. Three broad families are commonly used in production: graph-based indexes (HNSW — Hierarchical Navigable Small World graphs) offer excellent recall and query latency but higher memory overhead per vector, since they store explicit graph-navigation links; inverted-file/quantization-based indexes (IVF combined with product quantization, as implemented in libraries like FAISS) trade some recall for dramatically lower memory footprint by compressing vectors, which matters directly at the multi-terabyte scale estimated in Chapter 3; and managed vector database services (such as Milvus, or cloud-provider-managed offerings) wrap one of these underlying algorithms with operational conveniences like automated sharding, replication, and monitoring, at the cost of less low-level control and typically higher per-vector cost than self-hosting.

For a system at this scale, a common production pattern is a hybrid: use an HNSW-style index for a “hot” recent window of images (say, the last 90 days, when most theft detection actually matters, since copies tend to appear soon after an original is listed) where query latency matters most, and a more memory-efficient IVF+PQ index for the long-tail historical corpus, which is queried less frequently per-image but still needs to exist for the periodic re-scoring job described in Chapter 5 and for legal/audit lookups on older listings.

17.5 Testing & Evaluation Methodology

Just as with any machine-learning-driven system, correct code does not guarantee correct detections — the model can be functioning exactly as designed and still produce wrong verdicts if its accuracy characteristics don’t match the real-world threat pattern. Evaluation is a first-class engineering discipline here, not an afterthought.

Layers of Testing

The golden set for this system should specifically include hard negative pairs — genuinely different products that happen to look superficially similar (two different white sneakers, for example) — to actively measure and control the false-positive rate, not just confirm that obvious duplicates are caught.

17.9 Glossary of Terms Used in This Tutorial

Common interviewer pushbacks — and the reasoning that turns each of them into an answer rather than an argument.

Detecting stolen listing images at marketplace scale is fundamentally a throughput problem wearing a computer-vision costume. The interesting engineering isn’t just “run a similarity model” — it’s building a two-stage, queue-buffered, horizontally-scalable pipeline that keeps the expensive GPU work proportional to genuine risk, and pairing that detection signal with careful, conservative enforcement policy so the system protects honest sellers without punishing them.

If you remember one thing from this tutorial for an interview: at “requests per minute” scale, the architecture question is almost never “how do we respond fast enough” — it’s “how do we buffer, batch, and filter so the expensive resource is only ever spent on the genuinely ambiguous cases.”