System Design
June 23, 2026
2 min read
Designing Chat Distribution for Omnichannel Apps
A practical approach to normalizing channel events, routing conversations fairly, preventing duplicate assignment, and measuring outcomes.
- Laravel
- Node.js
- MySQL
Separate Ingestion from Assignment
An omnichannel inbox receives conversations from channels with different delivery guarantees, payloads, and rate limits. The first responsibility is to normalize each event into an internal conversation model. Preserve the provider's original event identifier, channel, customer identity, timestamps, and relevant routing metadata so that later processing can be traced back to its source.
Do not assign an agent inside a slow webhook request. Validate the signature, persist the event or an inbox record, acknowledge it quickly, and enqueue distribution. A durable event record gives operators a place to inspect retries and gives the application an idempotency key to reject duplicate deliveries. The exact signature and retry rules vary by provider, so verify those against the selected channel's documentation.
Make Routing Explainable
A useful first routing policy can consider team, language, product, current agent capacity, and whether the conversation is already owned. Begin with explicit rules and a deterministic tie-breaker, such as least recently assigned within an eligible team. Round-robin by itself can be unfair when agents have different active workloads, while a complex scoring model is hard to debug before the basics are measured.
Persist the assignment decision and its reason: which rule matched, which candidates were eligible, and why one agent was selected. Use a short database transaction or a carefully scoped lock when claiming a conversation so two workers cannot assign it simultaneously. Recheck capacity inside the claim operation; a capacity value calculated before a queue delay may already be stale.
Handle Reassignment and Recovery
Distribution is not finished after the first assignment. Agents go offline, customers reply after a conversation is closed, and supervisors may transfer work. Model these as explicit state changes with an audit trail, not as silent changes to an agent ID. Define what happens to an unanswered conversation, when a reassignment is allowed, and whether a transfer preserves the prior team's visibility.
Track queue age, time to first response, reassignment rate, and workload by team. These measures expose whether routing is helping or simply moving the backlog. Test duplicated webhooks, out-of-order messages, simultaneous workers, unavailable agents, and recovery after a provider outage. A clear, measurable policy is usually more valuable than an opaque algorithm, and each channel adapter can evolve without changing the core assignment contract.