Imagine a shady middleman standing between two shops. He tells you, a customer, “I have that exact sofa you want and I will sell it to you for a great price — just pay me directly.” You pay him. He then walks into a real furniture store across the street, buys that exact sofa using someone else’s stolen credit card and has the store ship it straight to your house. You get your sofa, so you are happy and leave a good review. The furniture store eventually finds out the card was stolen and reverses the charge, losing the sofa entirely. The middleman walks away with your money and never had a sofa, a warehouse or any real business at all.

This is exactly the mechanics of triangulation fraud, translated into online marketplace terms. A fraudulent seller lists a product on a marketplace (Amazon, eBay, Etsy or any multi-seller platform) that they do not actually own or stock. When a real buyer orders and pays, the fraudulent seller takes that payment, then uses a completely different, usually stolen, card to buy the same item from a legitimate retailer and has it shipped directly to the original buyer’s address. The buyer receives a real product and is often none the wiser, which is exactly what makes this fraud pattern so dangerous — the buyer-side experience looks completely normal, so complaints rarely trigger the investigation.

The name “triangulation” comes from the three-party shape of the scheme: the fraudulent seller sits between the buyer, who never suspects anything is wrong and the legitimate retailer, whose real inventory and real cardholder absorb all of the actual loss. The diagram below shows this triangle clearly.

Triangulation fraud has grown alongside the rise of open, multi-seller marketplaces. It became especially prevalent once large platforms lowered the barrier to becoming a seller — anyone can register, list products and start receiving payouts within days. Marketplaces such as Amazon Marketplace, eBay, Etsy and large regional platforms in India and Southeast Asia have all publicly discussed this fraud pattern as a persistent operational challenge, because the fraud is largely invisible from the buyer’s side and only becomes visible once the legitimate retailer or the victim cardholder disputes the charge, often weeks after the fraudulent seller has already been paid out and disappeared.

2.1 Why is this fraud pattern so hard to catch?

Triangulation fraud is uniquely difficult compared to most other e-commerce fraud patterns for a specific reason: from the marketplace’s point of view, the buyer-side transaction looks completely legitimate. The buyer pays with their own valid card, receives their item and is satisfied. There is no chargeback on the buyer’s side, no complaint, no obviously suspicious velocity of failed payments. The fraud signal lives almost entirely on the seller’s side — in the mismatch between what the seller claims to own and what they actually ship — and in a second transaction that happens entirely outside the marketplace’s own systems, at a different retailer altogether.

2.2 Why does this matter to a business?

2.3 Why is this a hard system design problem?

• The core evidence is off-platform. The actual fraudulent purchase happens at a different retailer’s website, which the marketplace has no direct visibility into. Detection must rely on indirect signals: seller behaviour, shipment patterns and inventory claims.
• It must be caught before payout, not after. Once the fraudulent seller has withdrawn funds, recovering the loss is far harder. This creates a hard real-time constraint: the system must assess seller and order risk within the payout processing window, which itself must operate under tight latency at huge scale.
• Massive scale. Large marketplaces process millions of orders per hour across millions of active sellers and the detection system must evaluate every single order and every seller behaviour change without becoming the platform’s bottleneck. At the scale specified for this design (millions of requests per minute), naive per-request database lookups or synchronous cross-service calls simply will not survive contact with real traffic.
• Legitimate drop-shipping looks similar. Many completely legitimate sellers use drop-shipping models, where they also do not hold physical inventory and have a supplier ship directly to the buyer. The system must distinguish “legitimate drop-shipping using a legitimate business relationship and the seller’s own valid payment method” from “triangulation fraud using someone else’s stolen payment method”, which is a genuinely subtle distinction.
• Sellers rotate identities. A banned fraudulent seller often reappears under a new account, a new business registration and a new bank account, so entity resolution and identity linkage across accounts becomes essential, not optional.

3.1 Drop-shipping versus triangulation fraud

Both patterns involve a seller who does not hold physical inventory and relies on a third party to fulfil the order. The critical difference is the payment method used for that third-party fulfilment purchase:

3.2 Entity linkage graph

Because triangulation fraud often involves the same fraudster operating multiple seller accounts or reusing the same shipping addresses, bank accounts or device fingerprints across accounts, a graph structure connecting sellers, buyers, addresses, bank accounts, devices and orders is one of the most powerful detection tools available. A single suspicious order is weak evidence; the same shipping address appearing across twelve different “new” seller accounts, all created in the last month, is very strong evidence.

3.3 Chargeback and dispute signals

A chargeback happens when a cardholder disputes a charge with their bank. In triangulation fraud, the chargeback lands on the legitimate retailer, not the marketplace, which is precisely why marketplaces cannot rely on their own chargeback data alone. Many marketplaces build data-sharing partnerships or monitor public retailer fraud advisories and correlate shipment tracking numbers reported by buyers against known patterns of disputed retail orders, to close this visibility gap.

3.4 Seller trust score and account age

Just like a credit score for a person, a seller trust score aggregates a seller’s history — account age, order volume, dispute rate, listing accuracy, prior warnings — into a single evolving risk indicator. New seller accounts inherently carry more risk simply because they have no track record, which is why most systems apply stricter scrutiny (holding payouts longer, requiring identity verification, capping order volume) during a defined probation period.

3.5 Payout holds versus payout blocks

A payout hold is a temporary delay releasing a seller’s earned funds while a risk signal is investigated — reversible, low-friction if wrong. A payout block is a harder, longer-term freeze applied once a pattern is confirmed. Building a system with a graduated response, rather than only a binary “pay or do not pay”, lets you act early on weak signals without unfairly punishing legitimate sellers who trip a soft signal.

3.6 Rules engine versus machine learning versus graph analysis

As with most fraud systems, no single technique catches everything. Rules catch known, well-understood patterns fast (for example, “seller’s declared warehouse country does not match the shipping carrier’s pickup location country”). Machine learning scoring captures subtler combinations of weaker signals across many order and seller attributes. Graph analysis catches identity and relationship patterns that neither rules nor a row-level ML model can see on their own, because the signal only exists when you look across many connected entities together.

4.1 Functional requirements

• Evaluate every order and every payout request for triangulation risk, returning Approve, Hold or Block.
• Maintain an identity linkage graph connecting sellers, buyers, shipping addresses, bank accounts and devices.
• Verify, where possible, that a seller’s claimed inventory ownership is plausible (matching declared warehouse location, supplier relationships and historical fulfilment origin patterns).
• Track seller-level behavioural velocity: new listings, order volume growth rate, shipping origin diversity and address reuse across accounts.
• Support a graduated response: soft flags, payout holds, payout blocks and account suspension, each reversible up to the point of full confirmation.
• Provide fraud analysts a case management workflow to review flagged sellers and orders, with full supporting evidence from rules, ML and graph signals.
• Feed confirmed fraud cases back into both the ML training pipeline and the entity linkage graph for future detection.
• Maintain a full audit trail of every decision, usable for regulatory response and seller disputes.

4.2 Non-functional requirements

4.3 Scale estimation for millions of requests per minute

This is the headline scale constraint for this design, so let us work through it carefully, the way an interviewer expects.

Target: sustain up to 5,000,000 requests per minute at peak
(this includes order placement, listing views/updates, and payout-triggering events combined)

Converting to requests per second:
5,000,000 requests / 60 seconds ~= 83,333 requests per second (RPS) sustained at peak

Assume roughly 15 percent of total requests actually require
a full fraud evaluation (order placement and payout triggers,
not simple browsing or listing views):
83,333 x 0.15 ~= 12,500 fraud evaluation RPS at peak

Fraud Decision Gateway capacity planning:
- Assume each stateless Fraud Decision Gateway pod can safely handle
  ~500 evaluation RPS given parallel calls to Rules Engine, ML Scoring,
  and Graph Service, each with strict timeouts
- Required pod count at peak: 12,500 / 500 = 25 pods minimum,
  with autoscaling headroom typically targeting 2 to 3x that for
  safety margin and sudden spikes: ~60 to 75 pods per active cell

Velocity Cache (Redis) sizing:
- Assume 50 million active seller/buyer/address/device keys tracked
  in rolling windows at any given time
- Each key's sliding window record: ~250 bytes
- 50,000,000 x 250 bytes ~= 12.5 GB of hot data,
  comfortably shardable across a Redis Cluster with headroom

Kafka event pipeline volume:
- Each order/payout event: ~3 KB including features and metadata
- At 12,500 evaluation RPS average: 12,500 x 3 KB ~= 37.5 MB/sec
  ~= 3.24 TB/day into Kafka, partitioned by seller ID for parallelism

Graph database sizing:
- Assume 200 million sellers, buyers, addresses, and devices as nodes,
  with an average of 6 edges per node from historical orders and shared attributes
- 200,000,000 nodes x 6 edges ~= 1.2 billion edges,
  requiring a horizontally partitioned graph database rather than a single-node graph store

The diagram below shows the full system, organised into the same familiar layers as any high-scale marketplace: edge and gateway, core marketplace services, the triangulation fraud detection platform, an asynchronous event and graph-building pipeline and the data layer.

5.1 Component responsibilities

Edge and Gateway Layer

• CDN / Edge Cache: Serves static storefront and listing page assets close to the user, absorbing a large share of read-heavy traffic before it reaches origin infrastructure — critical at millions-of-requests-per-minute scale.
• WAF (Web Application Firewall): Blocks known malicious request signatures and applies coarse IP reputation filtering before requests reach the application layer.
• Load Balancer: Distributes incoming traffic across API Gateway instances within each deployment cell (see Section 13), performing health checks and connection-level rate limiting.
• API Gateway: Handles authentication, request validation, per-seller and per-buyer rate limiting and routes requests to the correct backend service and cell.

Marketplace Core Services

• Listing Service: Owns the product catalog; new and updated listings pass through a lightweight risk check here too, since suspicious listing patterns (implausibly low prices, sudden bulk listing of high-demand items) are an early triangulation signal.
• Seller Onboarding Service: Manages seller registration, identity verification and the probation period for new sellers described in Section 3.4.
• Order Service: Owns order creation and lifecycle state.
• Payment Orchestrator Service: Coordinates payment capture from the buyer and payout release to the seller, calling the Fraud Decision Gateway before each payout is released.

Triangulation Fraud Detection Platform

• Fraud Decision Gateway: The stateless, horizontally scaled synchronous entry point that fans out to the Rules Engine, ML Scoring Service, Identity Linkage Graph Service and Inventory Verification Service in parallel, combining their outputs into one final decision within the latency budget.
• Rules Engine: Evaluates deterministic rules about seller behaviour and order patterns using data from the Velocity Cache.
• ML Scoring Service: Produces a real-time risk probability using features from the Feature Store, covering both order-level and seller-level risk signals.
• Identity Linkage Graph Service: Answers relationship queries against the graph database — for example, “how many distinct seller accounts share this exact shipping address or bank account”.
• Inventory Verification Service: Cross-checks a seller’s declared inventory source and shipment origin patterns against historical data, flagging implausible ownership claims.
• Velocity Cache: A sharded Redis Cluster holding sliding-window counters across sellers, buyers, addresses and devices.
• Feature Store: Serves pre-computed, low-latency features for online ML scoring, kept consistent with offline training data.

Async Event Pipeline

• Event Stream (Kafka): Every order, listing and payout event is published here, partitioned by seller ID for parallel, ordered processing per seller.
• Stream Processor: Computes rolling velocity aggregations and writes them back into the Velocity Cache and Feature Store.
• Graph Builder Job: Continuously updates the Identity Linkage Graph with new nodes and edges as new orders, accounts and shared attributes appear.
• Case Management Service: Groups related flagged sellers and orders into cases for fraud analyst review.
• Notification Service: Alerts trust and safety analysts, on-call engineers and can notify partner retailers of confirmed fraud patterns where data-sharing agreements exist.

Data Layer

• Order Database: Sharded Postgres, the system of record for orders and payments.
• Graph Database: A horizontally partitioned graph store (such as Amazon Neptune or JanusGraph) holding the full identity linkage graph.
• Analytics Warehouse: An OLAP store for historical fraud analysis and generating training data.
• Model Registry: Stores trained model versions with rollback support.

6.1 The synchronous decision path, step by step

The diagram below shows what happens between a buyer submitting an order and the marketplace deciding whether the associated seller payout should proceed normally, be held or be blocked.

6.2 Why the order always completes, even when risk is high

A subtle but important design decision: for buyer experience reasons, the order itself is almost never blocked at checkout based on seller-side triangulation risk, because the buyer has done nothing wrong and blocking their purchase would be a confusing, harmful false positive from their perspective. Instead, risk signals control the seller’s payout, which can be held or blocked without the buyer ever noticing anything unusual. This is a very different pattern from the card-testing fraud use case (buyer-side risk) and is worth explicitly contrasting in an interview if asked to compare the two.

6.3 Combining multiple signal types into one decision

6.4 Java example: the signal combiner

public class TriangulationDecisionCombiner {

    private static final double BLOCK_THRESHOLD = 0.8;
    private static final double HOLD_THRESHOLD  = 0.4;

    public PayoutDecision decide(
            GraphRiskSignal graphSignal,
            RulesVerdict rulesVerdict,
            double mlScore,
            InventoryConfidence inventoryConfidence) {

        // A confirmed fraud-ring graph match is treated as near-certain
        if (graphSignal.matchesKnownFraudRingSignature()) {
            return PayoutDecision.block("GRAPH_FRAUD_RING_MATCH");
        }

        if (rulesVerdict.isHardTrigger()) {
            return PayoutDecision.block(rulesVerdict.getReasonCode());
        }

        double combinedScore = (mlScore * 0.5)
                + (graphSignal.getRiskContribution() * 0.3)
                + (inventoryConfidence.getRiskContribution() * 0.2);

        if (combinedScore >= BLOCK_THRESHOLD) {
            return PayoutDecision.block("COMBINED_HIGH_RISK");
        }
        if (combinedScore >= HOLD_THRESHOLD) {
            return PayoutDecision.hold("COMBINED_MODERATE_RISK");
        }
        return PayoutDecision.approve();
    }
}

6.5 Java example: seller-level sliding window velocity in Redis

public class SellerVelocityChecker {

    private final RedisTemplate<String, String> redis;
    private static final long WINDOW_SECONDS         = 3600;
    private static final int  MAX_NEW_LISTINGS_PER_HOUR = 50;

    public boolean isSuspiciousListingBurst(String sellerId) {
        String key         = "velocity:seller_listings:" + sellerId;
        long   now         = System.currentTimeMillis();
        long   windowStart = now - (WINDOW_SECONDS * 1000);

        redis.opsForZSet().removeRangeByScore(key, 0, windowStart);
        redis.opsForZSet().add(key, String.valueOf(now), now);
        redis.expire(key, java.time.Duration.ofSeconds(WINDOW_SECONDS * 2));

        Long count = redis.opsForZSet().zCard(key);
        return count != null && count > MAX_NEW_LISTINGS_PER_HOUR;
    }
}

A confirmed triangulation fraud case rarely comes from a single order — it emerges as a seller’s behaviour accumulates evidence over time. The state diagram below shows the full lifecycle.

7.1 How the graph and velocity signals feed the lifecycle

Every state transition in the diagram above is triggered by signals produced elsewhere in the architecture. The transition from UnderWatch to Confirmed, for example, is typically driven by the Identity Linkage Graph Service detecting repeated shipment-origin mismatches or shared address patterns across multiple orders, combined with the Stream Processor’s rolling velocity aggregations crossing a defined threshold. This is why the async pipeline (Kafka, Stream Processor, Graph Builder Job) is just as important to this system’s effectiveness as the synchronous decision path — the synchronous path catches individual bad orders, while the async pipeline is what actually detects the pattern across time and across seller accounts that makes triangulation fraud identifiable in the first place.

7.2 Why the probation period for new sellers matters

New seller accounts are disproportionately used for triangulation fraud, because they have no history to build trust and because a banned fraudster’s fastest path back into the marketplace is simply registering again under a new identity. A defined probation period — with lower order value limits, delayed payouts and stricter inventory verification requirements — dramatically raises the cost of running triangulation fraud through freshly created accounts, without meaningfully harming genuine new sellers, most of whom start small anyway.

8.1 Key trade-off: detection speed versus evidence strength

Acting on a single suspicious signal (say, one address shared by two sellers) catches fraud early but risks many false positives, since address sharing sometimes has innocent explanations (family members, small business incubators, shared fulfilment centres). Waiting for stronger, accumulated evidence (repeated pattern across many orders and many linked accounts) is more accurate but slower, giving a fraud ring more time and more orders before detection. The graduated response model in Section 3.5 is the direct answer to this trade-off: act early with a soft, reversible response and escalate only as evidence strengthens.

8.2 Key trade-off: global consistency versus cell independence

The cell-based deployment model (Section 13) trades some global consistency for massive horizontal scalability — a fraud ring could, in principle, spread its accounts deliberately across different cells to avoid appearing connected within any single cell’s local graph and velocity data. This is addressed by a global, asynchronous cross-cell reconciliation job that periodically merges cell-local graphs into a global view, accepting a delay (typically minutes, not milliseconds) in exchange for the ability to scale each cell independently without cross-cell coordination on every request.

9.1 Where the bottlenecks are at this scale

9.2 Cell-based architecture: the core scaling strategy

At the scale required here (millions of requests per minute), a single monolithic deployment of any component, no matter how well it is scaled vertically, eventually hits a ceiling and worse, becomes a single blast-radius for any failure or bad deployment. The solution used throughout this design is a cell-based architecture: the entire fraud platform (API Gateway, Fraud Decision Gateway, Redis, Kafka and supporting services) is replicated into multiple independent “cells”, each responsible for a fixed shard of sellers (see the deployment diagram in Section 13). A request for a given seller is always routed to the same cell, which means each cell only needs to handle a fraction of total platform traffic and a failure or overload in one cell never affects sellers assigned to a different cell.

9.3 Caching strategy at scale

• Blocklist and known-fraud-ring cache: Local in-memory cache (Caffeine) on every Fraud Decision Gateway pod, refreshed from Redis via pub/sub invalidation, avoiding a network round trip for the highest-confidence, most frequently hit rejections.
• Graph 1-hop cache: Pre-computed “does this address / device / bank account already have a known risk flag” answers cached aggressively (seconds to low minutes TTL), since this is the single most frequently needed graph query.
• Feature cache tiering: Slowly changing seller-level features (account age, historical dispute rate) cached longer than fast-changing order-level features (current hour’s order count).

9.4 Algorithms and data structures for extreme scale

Consistent hashing for cell routing

Routing a seller to a cell needs to be fast, stable (the same seller should almost always land on the same cell, even as cells are added or removed) and evenly distributed. Consistent hashing is the standard solution: sellers are hashed onto a ring and cells own contiguous ranges of that ring, so adding or removing a cell only requires reshuffling a small fraction of sellers rather than the entire population.

Bloom filters for fast negative lookups

Before doing an expensive graph or database lookup to check “has this address ever been associated with a flagged seller”, a Bloom filter can answer “definitely not” instantly for the vast majority of addresses that have never appeared in any fraud case, at a small, tunable false-positive rate, dramatically cutting load on the more expensive exact-match systems behind it.

Approximate counting with HyperLogLog

Tracking “how many distinct shipping addresses has this seller used in the last 30 days” exactly requires storing every unique address, which gets expensive at scale across millions of sellers. HyperLogLog, a probabilistic data structure for approximate distinct counting, estimates this cardinality using a tiny, fixed amount of memory per seller, with a small, well-understood error margin — more than sufficient for a velocity-style risk signal.

Graph partitioning

At 200 million nodes and over a billion edges (Section 4.3), the graph database itself must be partitioned. A common approach is partitioning by entity type and by cell boundary where possible, accepting that some cross-partition edges (a fraud ring deliberately spanning cells) require the asynchronous cross-cell reconciliation job mentioned in Section 8.2 rather than a synchronous cross-partition query.

10.1 Redundancy within and across cells

Every stateful component within a cell (Redis, Kafka, Postgres) is deployed across multiple availability zones with automatic failover, exactly as in a single-region design. What is different here is that cells themselves are a redundancy boundary: if an entire cell becomes unhealthy, its assigned sellers can, in a well-designed system, be temporarily rerouted to a neighbouring cell with spare capacity, accepting a brief period of degraded (rules-only, cache-only) decisioning during the transition rather than a full outage for those sellers.

10.2 Graceful degradation

10.3 Idempotency at very high throughput

At millions of requests per minute, retries are frequent and expected. Every fraud decision request carries an idempotency key (the order or payout attempt ID) and the Fraud Decision Gateway short-circuits duplicate requests by checking a short-TTL idempotency record in Redis before doing any real work, both protecting velocity counters from double-counting and reducing unnecessary load on downstream services during retry storms.

11.1 Protecting sensitive seller and buyer data

The graph and velocity systems work with hashed or tokenised representations of sensitive identifiers (bank account numbers, government ID numbers used for seller verification) rather than raw values wherever possible, minimising the blast radius if any single component is compromised and reducing the platform’s exposure under relevant data protection and financial services regulations.

11.2 Protecting the fraud system from manipulation

A sophisticated fraud ring will actively probe and adapt to detection systems, so the platform itself needs defences against being reverse-engineered:

• Never expose specific hold or block reasons to sellers. A generic “your payout is under review” message prevents a fraud ring from learning exactly which signal triggered detection and adjusting their next attempt accordingly.
• Strong authentication and full audit logging on the Trust and Safety Dashboard and any tool capable of modifying rules, thresholds or graph data, since these are exactly the internal tools an insider threat or compromised credential would target.
• Rate limit and monitor seller account creation itself, since rapid, automated creation of many new seller accounts is often the first observable step of a triangulation fraud ring assembling its operation.
• Periodically rotate detection thresholds and add controlled randomness to exactly where soft-flag boundaries sit, making systematic probing of the system’s limits less reliable for an attacker.

11.3 Identity verification for sellers

Because a banned fraudster’s fastest path back into the marketplace is registering a new account, stronger identity verification at onboarding (government ID checks, bank account ownership verification, business registration validation where applicable) raises the cost of creating new fraudulent identities. This should be risk-based: low-risk categories and low order-value sellers can onboard with lighter verification, while higher-risk categories (historically correlated with triangulation fraud, such as high-demand electronics) can require stronger verification before full marketplace privileges are granted.

12.1 Key metrics to track

12.2 Logging and traceability

Every decision is logged with a structured record: a trace ID shared across every service touched, every rule that fired, the raw ML score and model version, the specific graph signals contributing to the decision and the final outcome. This supports both internal debugging and the seller dispute and appeal process required by most marketplace trust and safety policies.

12.3 Distributed tracing across a cell-based system

Because a single decision fans out across the Rules Engine, ML Scoring Service, Linkage Graph Service and Inventory Verifier, all within a specific cell, distributed tracing (OpenTelemetry with a propagated trace ID) is essential — and trace data should be tagged with the originating cell ID, so latency regressions can be isolated to a specific cell rather than investigated as a vague, platform-wide slowdown.

12.4 Alerting philosophy

• Alert on rate-of-change and per-cell deviation from the platform-wide baseline, not just absolute thresholds, since normal traffic patterns vary significantly by cell composition and time zone.
• Separate system health alerts (latency, errors, cell imbalance) from fraud pattern alerts (a new suspected fraud ring detected), routed to engineering on-call and trust and safety analysts respectively.
• Build a live “active fraud rings” dashboard surfacing the graph’s most recently formed high-risk clusters, so analysts can act while a ring is still small rather than after it has scaled up.

The deployment diagram below shows the cell-based topology introduced in Section 9.2, which is the foundation of how this system reaches millions of requests per minute without any single cluster becoming a bottleneck.

13.1 Containers and orchestration within each cell

Each service within a cell (Fraud Decision Gateway, Rules Engine, ML Scoring Service, Linkage Graph Service) runs as a container on Kubernetes, with Horizontal Pod Autoscaling driven by request rate and queue depth. Because each cell only serves a fixed shard of sellers, autoscaling within a cell is far more predictable than it would be for a single global cluster absorbing all platform traffic at once.

13.2 Rolling out new cells

Adding capacity at this scale means adding a new cell, not just adding more pods to an existing cluster. Using consistent hashing (Section 9.4) for seller-to-cell routing means a new cell can absorb a defined slice of sellers from existing cells with a bounded, predictable amount of data movement, rather than requiring a full re-shard of the entire seller population.

13.3 Canary deployments per cell

New rule sets and model versions are rolled out to a single cell first, with close comparison of that cell’s decision rates and latency against the platform-wide baseline, before progressively rolling out to remaining cells. This cell-by-cell canary strategy naturally limits the blast radius of a bad deployment to a fraction of total sellers, which is especially valuable given how directly a bad fraud decision affects real sellers’ cash flow.

13.4 Infrastructure as code for a cell-based system

Given that this design assumes cells will be added over time as traffic grows, the entire cell definition (Kubernetes manifests, Redis shard configuration, Kafka partition assignments) is templated as reusable Infrastructure as Code (Terraform modules), so spinning up a new cell is a repeatable, tested, single-command operation rather than manual, error-prone work.

13.5 Cost optimisation at this scale

• Route the cheapest, highest-confidence checks (blocklist and cache lookups) first, reserving expensive graph traversals and ML inference for requests that do not get resolved by cheap checks alone.
• Right-size each cell independently based on its actual seller population’s traffic pattern, rather than provisioning every cell identically for worst-case peak.
• Tier storage: keep only hot, recent velocity and graph-cache data in memory; move historical graph and transaction data to cheaper storage after a defined retention window.

14.1 Choosing the right store for each job

14.2 Sharding strategy across cells

Every data store that participates in the synchronous decision path — Redis, the graph database and Postgres — is sharded consistently by seller ID within each cell, matching the cell routing strategy from Section 9.2. This alignment is deliberate: it means a single seller’s complete data footprint (velocity, graph neighbourhood, order history) lives within one cell, avoiding expensive cross-cell queries for the vast majority of decisions.

14.3 Load balancing strategy

At the global layer, anycast DNS and a global load balancer route each request to the nearest healthy region and then to the correct cell based on the seller ID hash. Within a cell, a standard Layer 7 load balancer distributes traffic across API Gateway instances using least-outstanding-requests. Internal service-to-service calls within a cell use client-side load balancing integrated with service discovery, avoiding an extra network hop through a central load balancer for latency-critical internal calls like the Fraud Decision Gateway’s fan-out to the Rules Engine and ML Scoring Service.

14.4 Cross-cell data consistency

As discussed in Section 8.2, cells are intentionally not strongly consistent with each other in real time. A dedicated asynchronous cross-cell reconciliation job periodically merges newly discovered graph edges and confirmed fraud patterns across all cells, so that a fraud ring’s presence discovered in one cell eventually (typically within minutes) informs detection in every other cell, without requiring synchronous cross-cell coordination on the hot path.

15.1 The core fraud evaluation API

POST /v1/fraud/evaluate-payout
Content-Type: application/json
Idempotency-Key: payout_7f3a9c12

{
  "orderId":               "order_9182a3f0",
  "sellerId":              "seller_44821",
  "buyerId":               "buyer_20194",
  "shippingAddressHash":   "sha256:6b3f2e...",
  "orderValue":            249.99,
  "currency":              "USD",
  "listingCategory":       "electronics",
  "sellerAccountAgeDays":  12,
  "declaredWarehouseCountry": "US"
}

Response 200 OK:
{
  "orderId":          "order_9182a3f0",
  "decision":         "HOLD",
  "riskScore":        0.63,
  "reasonCodes":      ["GRAPH_SHARED_ADDRESS", "NEW_SELLER_HIGH_VALUE"],
  "modelVersion":     "triangulation-model-v9",
  "cellId":           "cell-b",
  "decisionLatencyMs": 47
}

15.2 Internal service boundaries

• Rules Engine service: owns rule evaluation logic; rule definitions are stored in a versioned configuration store so trust and safety analysts can update them without a code deploy.
• ML Scoring service: owns model loading, feature retrieval orchestration and inference, hiding model-specific complexity behind a simple scoring API.
• Identity Linkage Graph service: owns graph storage and query execution, exposing both fast cached lookups and slower deep-traversal query endpoints as clearly distinct API operations with different latency expectations.
• Case Management service: owns the lifecycle of flagged sellers and cases, exposing APIs for the analyst dashboard.

15.3 Synchronous versus asynchronous communication

The Fraud Decision Gateway’s fan-out calls to the Rules Engine, ML Scoring Service and the fast graph lookup path are synchronous, using gRPC for low serialisation overhead and strict deadline propagation. Deep graph traversal, graph building, analytics and model feedback are all asynchronous, flowing through Kafka, since none of this needs to block a payout decision that already has enough signal from the fast synchronous checks.

16.1 Useful design patterns

16.2 Anti-patterns to avoid

17.1 Best practices

• Always log the full reasoning behind every decision — every rule, graph signal and model score that contributed — since this drives both analyst review and seller dispute resolution.
• Run new rules, thresholds and model versions in shadow mode on a single cell first, comparing outcomes against the live baseline before any real payout impact.
• Design the graduated response (soft flag, hold, block) explicitly and make every automated action reversible until human confirmation, given how directly a wrong decision affects a legitimate seller’s business.
• Invest as much in the async graph-building and reconciliation pipeline as in the synchronous decision path — the pattern detection that actually catches triangulation fraud rings lives largely in the async layer.
• Treat cell capacity planning as an ongoing operational practice, not a one-time design decision, since seller population and traffic patterns shift over time.
• Build strong data-sharing relationships with major partner retailers where possible, since off-platform chargeback signals close a real visibility gap that no amount of internal-only signal can fully replace.

17.2 Common mistakes

• Optimising purely for buyer-side fraud signals and missing that triangulation fraud is fundamentally a seller-behaviour and off-platform visibility problem.
• Under-investing in the identity linkage graph because it is the least familiar, most operationally complex component, even though it is often the single most effective tool against coordinated fraud rings.
• Designing for average throughput instead of true peak and discovering the cell-based architecture’s benefits only after an outage caused by a single over-scaled cluster.
• Ignoring the seller experience impact of false positives, leading to legitimate seller churn that quietly undermines the whole marketplace’s supply side.
• Failing to build the cross-cell reconciliation job early, leaving an exploitable gap for fraud rings that learn to distribute themselves across cell boundaries.

Q: Can triangulation fraud be stopped completely?

No system eliminates it entirely, since some of the critical evidence (the fraudulent purchase at the legitimate retailer) happens entirely outside the marketplace’s visibility. The realistic goal is to catch it fast enough and often enough, that running a triangulation fraud operation stops being profitable, pushing fraudsters toward easier, less well-defended targets.

Q: How do you avoid punishing legitimate drop-shippers?

By focusing detection on the payment method and relationship evidence, not the drop-shipping business model itself (Section 3.1). A legitimate drop-shipper with a documented, repeatable supplier relationship and consistent shipping origins over time looks very different, structurally, from a seller whose fulfilment source varies unpredictably and whose declared warehouse location never matches actual shipment origins.

Q: Why hold payouts instead of just banning suspicious sellers immediately?

Because early signals are often uncertain and immediately banning a seller based on a single ambiguous signal risks significant harm to a legitimate business. The graduated response model (Section 3.5) exists specifically to let the system act early and reversibly, escalating to a permanent ban only once evidence is strong enough to justify that much more severe, much less reversible action.

Q: How does this system handle a fraud ring that deliberately splits itself across multiple cells?

This is directly addressed by the asynchronous cross-cell reconciliation job described in Sections 8.2 and 14.4, which periodically merges graph data across all cells specifically to catch patterns that a single cell’s local view would not see on its own.

Q: Does this system need to comply with any specific regulations?

Yes — seller identity verification touches Know Your Customer (KYC) and Know Your Business (KYB) style obligations in many jurisdictions and the graph and velocity systems handle personally identifiable information (addresses, bank details) that fall under data protection regulations. The audit trail and reason-code logging described in Section 12.2 support both regulatory reporting and the seller appeal process that most jurisdictions’ consumer protection frameworks require.

Designing a triangulation fraud detection system is a distinctive system design problem because the core evidence of the fraud lives partly outside the platform you are building, the correct point of intervention is the seller’s payout rather than the buyer’s order and the fraud pattern itself is fundamentally relational — making a graph-based approach not just useful but close to essential. Layer on a requirement to sustain millions of requests per minute and the design also becomes a strong test of horizontal scaling strategy, specifically cell-based architecture, consistent hashing and careful separation of cheap synchronous checks from expensive asynchronous ones.