Prerequisites

What Ordering Actually Means

"We need events in order" is among the most common requirements stated in design discussions, and among the least precise. The word covers several distinct guarantees with very different costs.

Total Ordering and Its Price

Total ordering requires every participant to agree on a single sequence covering all events. Achieving this across nodes requires consensus on every event.

A single ordering point caps system throughput at the rate that point can process, regardless of how many nodes exist elsewhere. Adding capacity does not help.

Partial Ordering by Partition

The practical compromise is ordering within partitions and no ordering across them. Events sharing a key are sequenced, while independent keys proceed in parallel.

function partitionFor(orderingKey, partitionCount) {
    let hash = 0;

    for (let i = 0; i < orderingKey.length; i += 1) {
        hash = ((hash << 5) - hash) + orderingKey.charCodeAt(i);
        hash |= 0;
    }

    return Math.abs(hash) % partitionCount;
}

function publishEvent(event, topic) {
    const orderingKey = selectOrderingKey(event);

    return topic.publish({
        partition: partitionFor(orderingKey, topic.partitionCount),
        key: orderingKey,
        payload: event
    });
}

function selectOrderingKey(event) {
    switch (event.type) {
        case "order.created":
        case "order.updated":
        case "order.cancelled":
            return `order:${event.orderId}`;

        case "inventory.adjusted":
            return `sku:${event.sku}`;

        case "account.debited":
        case "account.credited":
            return `account:${event.accountId}`;

        default:
            return `entity:${event.entityId}`;
    }
}

Hot Partitions

Ordering by key concentrates all events for that key onto one partition and one consumer. Popular keys therefore become throughput bottlenecks.

Causal Ordering

Causal ordering sits between total and partial. It guarantees that causally related events are observed in order, while genuinely independent events may be seen in any sequence.

class CausalDeliveryBuffer {
    constructor(nodeId) {
        this.nodeId = nodeId;
        this.delivered = {};
        this.pending = [];
    }

    receive(message) {
        this.pending.push(message);
        return this.drainDeliverable();
    }

    drainDeliverable() {
        const released = [];
        let progressed = true;

        while (progressed) {
            progressed = false;

            for (let i = 0; i < this.pending.length; i += 1) {
                const message = this.pending[i];

                if (this.dependenciesSatisfied(message)) {
                    this.pending.splice(i, 1);
                    this.applyMessage(message);
                    released.push(message);
                    progressed = true;
                    break;
                }
            }
        }

        return released;
    }

    dependenciesSatisfied(message) {
        for (const [node, required] of Object.entries(message.deps)) {
            const seen = this.delivered[node] ?? 0;

            if (node === message.origin) {
                if (seen !== required - 1) return false;
            } else if (seen < required) {
                return false;
            }
        }

        return true;
    }

    applyMessage(message) {
        this.delivered[message.origin] =
            message.deps[message.origin];
    }
}

What Breaks Ordering

Even a system designed for ordered delivery will encounter disorder. The sources are worth enumerating, because each requires a different response.

Designing for Disorder

Rather than strengthening ordering guarantees, the more robust approach is often to make operations insensitive to sequence.

-- Version guard: only newer updates are applied
UPDATE order_status
SET status       = :new_status,
    version      = :incoming_version,
    updated_at   = CURRENT_TIMESTAMP
WHERE order_id   = :order_id
  AND version    < :incoming_version;

-- Zero rows affected means a stale event, safely ignored

const LEGAL_TRANSITIONS = {
    created:   ["confirmed", "cancelled"],
    confirmed: ["packed", "cancelled"],
    packed:    ["shipped", "cancelled"],
    shipped:   ["delivered"],
    delivered: [],
    cancelled: []
};

function applyStatusEvent(currentStatus, event) {
    const permitted = LEGAL_TRANSITIONS[currentStatus] ?? [];

    if (!permitted.includes(event.targetStatus)) {
        return {
            applied: false,
            reason: `illegal transition ${currentStatus} to ${event.targetStatus}`,
            action: "quarantine-for-review"
        };
    }

    return { applied: true, newStatus: event.targetStatus };
}

Commutative Versus Order-Dependent

Consumer Parallelism Within Order

Strict ordering appears to forbid parallelism, but parallelism is achievable when work is grouped by ordering key rather than processed strictly one at a time.

async function processBatchRespectingOrder(messages, handler) {
    const groups = new Map();

    for (const message of messages) {
        const key = message.orderingKey;

        if (!groups.has(key)) {
            groups.set(key, []);
        }

        groups.get(key).push(message);
    }

    const results = await Promise.all(
        Array.from(groups.entries()).map(async ([key, group]) => {
            const processed = [];

            for (const message of group) {
                processed.push(await handler(message));
            }

            return { key, processed };
        })
    );

    return results;
}

Ordering Across Services

Ordering guarantees rarely survive service boundaries. Each hop introduces buffering, retries, and independent scheduling that can reorder events.

Detecting Disorder

Out-of-order processing frequently goes unnoticed because the resulting state looks plausible. Explicit detection is worthwhile.

class SequenceMonitor {
    constructor() {
        this.lastSeen = new Map();
    }

    check(orderingKey, sequence) {
        const previous = this.lastSeen.get(orderingKey);

        if (previous === undefined) {
            this.lastSeen.set(orderingKey, sequence);
            return { status: "first" };
        }

        if (sequence === previous + 1) {
            this.lastSeen.set(orderingKey, sequence);
            return { status: "in-order" };
        }

        if (sequence <= previous) {
            return {
                status: "out-of-order",
                expected: previous + 1,
                received: sequence
            };
        }

        this.lastSeen.set(orderingKey, sequence);

        return {
            status: "gap-detected",
            expected: previous + 1,
            received: sequence,
            missing: sequence - previous - 1
        };
    }
}

A Worked Example

Consider an e-commerce platform and the ordering requirement for each event stream.

Monitoring

Common Design Mistakes

System Design Interview Discussion

Design Checklist

Knowledge Check

Summary

Ordering is not a single guarantee. Total order, causal order, partial order, and FIFO per channel differ substantially in both promise and cost, and a requirement stated simply as "in order" is underspecified.

Total ordering requires consensus on every event, capping throughput at the sequencer's capacity and eliminating parallelism. It is affordable only over a low-volume critical subset such as configuration or membership changes.

Partition-scoped ordering is the practical compromise. Events sharing a key are sequenced while independent keys proceed concurrently. The key choice is the central design decision: too coarse destroys parallelism, too fine breaks correctness, and popular keys create partition-level bottlenecks that adding partitions cannot resolve.

Retries, rebalances, repartitioning, and service boundaries all break ordering in practice. The more resilient response is usually to design operations that tolerate disorder through commutativity, version guards, state transfer, and explicit state machines, rather than to build infrastructure guaranteeing a sequence that will be broken anyway.