Prerequisites

What Is Fan-Out?

Fan-out is a distributed-system pattern in which one incoming request, event, or unit of work produces multiple downstream operations. Those operations may run across several services, workers, queues, consumers, partitions, or search shards.

For example, a search coordinator may send one query to every relevant index shard. Each shard searches its local documents and returns its best candidates. Similarly, one published event may be delivered to several independent consumers.

Fan-Out and Fan-In

Fan-out distributes work, while fan-in collects the resulting outputs. The two patterns frequently appear together.

Common Forms of Fan-Out

Fan-Out in Distributed Search

A large search index is commonly divided into shards. Each shard holds only part of the indexed document collection. When a query can match documents on multiple shards, a coordinator distributes the query to those shards.

1. The client submits a search query.
2. The coordinator analyzes filters and routing information.
3. The query is sent to every required shard in parallel.
4. Each shard evaluates matching documents locally.
5. Each shard returns its highest-scoring candidates.
6. The coordinator merges and reranks the candidates.
7. The final page of results is returned to the client.

Global Top-K Selection

Suppose there are \(S\) shards and each shard returns its local top \(K\) candidates. The coordinator may need to examine as many as:

If 20 shards each return 100 candidates, the coordinator receives up to 2,000 candidates before selecting the final global result. This is an example for understanding the calculation, not a required production configuration.

async function distributedSearch(query, shards, limit) {
    const requests = shards.map(function (shard) {
        return searchShard(shard, query, limit);
    });

    const shardResponses = await Promise.allSettled(requests);

    const candidates = shardResponses
        .filter(function (response) {
            return response.status === "fulfilled";
        })
        .flatMap(function (response) {
            return response.value.results;
        });

    return candidates
        .sort(function (first, second) {
            return second.score - first.score;
        })
        .slice(0, limit);
}

This simplified example sends requests concurrently, retains successful responses, combines their candidates, and selects the highest-scoring results. A production implementation must also define timeout, retry, deduplication, pagination, and partial result behavior.

Scatter-Gather

Scatter-gather is a common request pattern closely related to fan-out and fan-in. The coordinator scatters requests across multiple destinations and gathers their responses.

Tail Latency

In a synchronous fan-out operation, the overall response often depends on the slowest required downstream request. Adding more destinations increases the possibility that at least one operation will be slow or unavailable.

This simplified formula assumes parallel execution. It shows why average shard latency alone is insufficient. The coordinator should also monitor slowest-shard latency, timeout rates, and the distribution of end-to-end response times.

Event Fan-Out with Publish and Subscribe

In publish-subscribe systems, a producer publishes one event to a topic. Multiple subscriber groups can independently receive that event and perform separate business operations.

{
    "eventId": "evt-6729",
    "eventType": "ProductUpdated",
    "entityId": "product-501",
    "occurredAt": "2026-09-24T05:00:00Z",
    "schemaVersion": 3,
    "data": {
        "name": "Wireless Keyboard",
        "price": 2499.00,
        "available": true
    }
}

Each consumer should use the stable event identifier to make retries safe. Consumers should also tolerate compatible schema evolution and avoid depending on the processing speed of other subscribers.

Fan-Out on Write

Fan-out on write, also called the push model, distributes an item when it is created. In a social feed, a newly published post may be inserted into the precomputed feed of each follower.

Here, \(F\) is the number of recipients and \(C\) is the number of downstream writes required for each recipient. A publisher with a large audience may therefore create a significant write burst.

Fan-Out on Read

Fan-out on read, also called the pull model, stores content once in the publisher's stream. When a user requests a feed, the system reads recent items from relevant publishers and merges them.

Hybrid Fan-Out

A hybrid design applies different strategies to different publishers, recipients, queries, or workloads. For example, ordinary publishers may use fan-out on write, while unusually high-follower publishers are merged into the feed during reads.

The routing decision may consider follower count, user activity, content type, permission model, write rate, feed-read rate, and current system capacity.

Fan-Out Amplification

Fan-out creates amplification because one external operation becomes several internal operations.

Here, \(Q_{\text{external}}\) is the incoming request rate and \(F\) is the average number of downstream destinations. Retries, replicas, and secondary workflows may increase the actual load further.

Partial Failure

A fan-out operation may succeed on some destinations and fail or time out on others. The system must define whether partial output is acceptable.

Retries and Retry Storms

Retrying every failed branch immediately can multiply load during an outage. If one request fans out to many services and each layer retries independently, the dependency may receive far more traffic than normal.

async function callWithRetry(operation, options) {
    let attempt = 0;

    while (attempt < options.maxAttempts) {
        try {
            return await operation();
        } catch (error) {
            attempt += 1;

            if (attempt >= options.maxAttempts) {
                throw error;
            }

            const exponentialDelay =
                options.baseDelayMs * Math.pow(2, attempt - 1);

            const jitter =
                Math.floor(Math.random() * options.jitterMs);

            await sleep(exponentialDelay + jitter);
        }
    }
}

Backpressure and Concurrency Control

Unbounded fan-out can exhaust connection pools, threads, memory, queue capacity, or downstream service limits. The coordinator should restrict how many branches are active simultaneously.

async function mapWithConcurrency(items, limit, worker) {
    const results = new Array(items.length);
    let nextIndex = 0;

    async function runWorker() {
        while (true) {
            const currentIndex = nextIndex;
            nextIndex += 1;

            if (currentIndex >= items.length) {
                return;
            }

            results[currentIndex] =
                await worker(items[currentIndex]);
        }
    }

    const workers = [];

    for (let index = 0; index < limit; index += 1) {
        workers.push(runWorker());
    }

    await Promise.all(workers);

    return results;
}

Selective Fan-Out

A system should avoid broadcasting every request to every destination when routing metadata can identify a smaller target set.

A search query filtered by region, tenant, date, or category may be routed only to shards that can contain matching documents. Routing metadata must remain accurate enough to avoid missing valid results.

Ranking and Pagination

Distributed ranking is more complex than independently sorting results on each shard. A document's local position does not automatically determine its global position.

Each shard commonly returns more candidates than the final page requires. The coordinator merges candidates, applies consistent scoring rules, removes duplicates, and produces the requested page.

Idempotency and Deduplication

Asynchronous fan-out frequently uses at-least-once delivery. Therefore, the same event or task may reach a consumer more than once.

BEGIN;

INSERT INTO processed_events (
    consumer_name,
    event_id,
    processed_at
)
VALUES (
    'search-indexer',
    'evt-6729',
    CURRENT_TIMESTAMP
)
ON CONFLICT (consumer_name, event_id) DO NOTHING;

UPDATE search_documents
SET
    title = 'Wireless Keyboard',
    price = 2499.00,
    is_available = TRUE
WHERE product_id = 501;

COMMIT;

In a real implementation, the deduplication record and business update must be coordinated so a crash cannot mark an event complete without applying its effect, or apply the effect without recording completion.

Monitoring Fan-Out

Common Design Mistakes

System Design Interview Discussion

Production Readiness Checklist

Knowledge Check

Summary

Fan-out distributes one unit of work across multiple downstream destinations. It supports parallel processing, distributed search, publish-subscribe delivery, feed generation, notifications, indexing, and large-scale data processing.

Distributed search commonly combines fan-out with fan-in. A coordinator sends a query to relevant shards, gathers local candidates, deduplicates them, merges their scores, and returns the final global results.

Fan-out on write performs additional work during publication to make reads faster. Fan-out on read stores content more centrally and performs aggregation when the user requests it. Hybrid designs use both strategies according to audience size, activity, cost, and freshness requirements.

Reliable fan-out requires selective routing, concurrency limits, backpressure, deadlines, bounded retries, idempotency, deduplication, partial-failure policies, and detailed monitoring of downstream amplification and tail latency.