Design Message Queue for Chat - System Design | WinJob

Problem Statement & Context

You are designing a message queue for chat — the durable log between chat APIs, push delivery, search indexing, and compliance export. This section focuses on chat message queue backbone. Interviewers at WhatsApp, Slack, and Discord expect you to treat the queue as the system of record for message facts while keeping user-visible latency on the push path under control.

Point 1.1: decouple chat ingress from push fan-out and search indexing
Point 1.2: WhatsApp-scale offline buffering with per-device cursors
Point 1.3: Slack workspace isolation as separate topic namespaces

Mechanism

Producers append immutable records to partition logs; brokers replicate to in-sync replicas before acknowledging. Consumers advance offsets independently per consumer group, which is how the same chat event fans out to push notification workers, Elasticsearch indexers, and warehouse connectors without duplicating storage. When decouple chat ingress from push fan-out and search indexing, the design response must name which tier breaks (durability, ordering, or latency) and what operational knob you turn.

Interview phrasing

State assumptions aloud: peak 1.4M messages/s, average payload 1.2KB, RF=3 replication, and conversationId as the partition key unless the channel exceeds per-partition throughput — then introduce sub-shards with a server-assigned seq field for total order within the conversation. Mention idempotent producers and at-least-once consumers with dedup stores; avoid claiming true exactly-once end-to-end unless you show transactional outbox boundaries.

Failure mode to volunteer

If a broker loses disk, ISR shrinks and produce latency spikes; you throttle non-human producers first, pause analytics consumers, and fail over partition leadership to healthy racks. For hot partitions, split by hash(conversationId, subShard) while preserving client-visible ordering via sequence numbers — interviewers reward this more than vague “add Kafka clusters.”

Signal	Target
Produce p99 ack	25 ms (same region)
Push consumer lag	< 2 s p99 normal load
Retention	7 d hot + tiered archive
Durability	No loss after min ISR ack

javaOne Dark Pro

1 public record ChatEnvelope(String tenantId, String conversationId, long seq, byte[] payload) {}

pythonOne Dark Pro

1 def partition_key(conversation_id: str, shard_count: int) -> int:
2     return zlib.crc32(conversation_id.encode()) % shard_count

typescriptOne Dark Pro

1 export interface ProduceRequest {
2   topic: string;
3   key: string;
4   value: Uint8Array;
5   idempotencyKey: string;
6 }

Why interviewers care

Message Queue for Chat interviews reward crisp scope, explicit trade-offs, and failure stories—not generic microservice diagrams.

Interview checkpoint

Name one failure story for Problem Statement & Context that proves you understand real outages, not happy-path diagrams.

Key Highlights

•Problem Statement & Context: durable log for chat fan-out
•Partition by conversation with hot-key mitigation
•Separate consumer groups for push vs search lag

1	def partition_key(conversation_id: str, shard_count: int) -> int:
2	return zlib.crc32(conversation_id.encode()) % shard_count

1	export interface ProduceRequest {
2	topic: string;
3	key: string;
4	value: Uint8Array;
5	idempotencyKey: string;
6	}