Interview Perspective

Strong answer direction: clarify 1:1 vs groups, offline delivery, multiple devices, read receipts, media, and E2EE before drawing boxes. What interviewer is testing: whether you can shrink a huge problem into an interview-sized core. Read deeper: Offline Message Sync and End-to-End Encryption Impact.

• What retention assumption are you making? — Label it explicitly as an illustrative product assumption, because retention shapes storage cost and sync backlog.
• Do edits, deletes, or reactions belong in the MVP? — Usually mention them as bounded extensions, not as the first thing you optimize for.

Strong answer direction: simplify group fan-out, membership, and giant receipt-explosion concerns; keep durable acceptance, routing, sync, and multi-device. What interviewer is testing: whether you can reduce complexity when scope shrinks. Read deeper: Group Message Fan-Out.

• Would you still keep separate gateways? — Maybe not at small scale; justify with connection count and operational goals.

Strong answer direction: messaging is bidirectional and latency-sensitive, so one persistent duplex connection is the cleanest fit. What interviewer is testing: your ability to compare alternatives instead of naming the default by reflex. Read deeper: WebSocket vs SSE vs Long Polling.

• What are the operational downsides of WebSocket? — Connection draining, reconnect storms, socket buffers, heartbeat cost, and long-lived connection management.

Strong answer direction: connection lifecycle and message processing scale differently; splitting them gives independent scaling and failure isolation. What interviewer is testing: can you justify service boundaries from workload differences. Read deeper: WebSocket Gateway Internals.

• When would you combine them? — At modest scale where fewer moving parts matter more than independent scaling.

Strong answer direction: registry returns multiple device or session routes, not one user route. What interviewer is testing: whether you naturally model multi-device. Read deeper: Connection Registry & Multi-Device Routing.

• What if the registry entry is stale? — Target gateway rejects it, service re-looks up, then falls back to sync or push if no live route remains.

Strong answer direction: the server durably accepted the logical message according to the write contract; it does not mean recipient delivered, read, or push succeeded. What interviewer is testing: guarantee precision. Read deeper: Message Write State Machine.

• Why is that distinction important? — Because every later retry, receipt, and outage explanation depends on it.

Strong answer direction: retry with the same client-generated idempotency key. What interviewer is testing: whether you see ambiguity as normal. Read deeper: Message Idempotency.

• Why is read-before-write dedup unsafe? — Another worker can win the race between the read and the insert.

Strong answer direction: the retry must return the original server message identity and sequence. What interviewer is testing: canonical messaging correctness reasoning. Read deeper: ACK Lost After Durable Write.

• How do you make that atomic? — Use conditional insert, uniqueness, transaction, or equivalent durable idempotency record.

Strong answer direction: per-conversation ordering, not global ordering. What interviewer is testing: whether you right-size the guarantee. Read deeper: Message Ordering & Sequencing.

• Would timestamps be enough? — No—clock skew and concurrency make them a poor strict ordering source.

Strong answer direction: serialize accepted writes through a conversation ordering authority—ordered log partition, sequencer owner with fencing, or storage conditional update. What interviewer is testing: failure-aware ordering design. Read deeper: Message Ordering & Sequencing.

• What if the sequencer dies? — New owner needs a higher epoch; stale owner writes must be rejected.

Strong answer direction: bounded buffering plus gap repair, then fall back to sync if needed. What interviewer is testing: client-visible correctness under transport reordering. Read deeper: Message Gap Recovery.

• Do you just wait 500 ms? — No fixed wait is universally correct; bounds depend on UX and network assumptions.

Strong answer direction: authenticate the device, present its durable cursor, replay missed message and receipt events, advance cursor after safe apply. What interviewer is testing: recovery-path thinking, not just happy-path push. Read deeper: Offline Message Sync.

• Do you query every conversation? — Not as the primary reconnect path at scale.

Strong answer direction: a durable checkpoint meaning “all changes up to here are safely applied.” What interviewer is testing: whether you can name an authoritative sync primitive. Read deeper: Offline Message Sync.

• What if the cursor expired? — Switch to full reconciliation or snapshot-based recovery.

Strong answer direction: to all relevant active device sessions, then aggregate to a product-level delivery state such as “delivered when any active device ACKs.” What interviewer is testing: multi-device routing plus semantic clarity. Read deeper: Connection Registry & Multi-Device Routing and Message Delivery Receipts.

• How do the sender's own devices stay converged? — Send and sync events also fan out to the sender's other devices.

Strong answer direction: remove routing state, invalidate or rotate any device-specific crypto or session state, and stop future delivery to that device. What interviewer is testing: lifecycle completeness. Read deeper: End-to-End Encryption Impact.

• Does old history remain on the removed device? — That depends on product and crypto policy; removal mainly affects future routing and key trust.

Strong answer direction: evolve from direct or mostly synchronous group delivery, to async fan-out, to broadcast/channel-style store-once plus audience delivery semantics. What interviewer is testing: ability to shift architecture with audience size. Read deeper: Group Message Fan-Out and Broadcast / Channel Messaging.

• What is the group-size threshold? — It depends on workload; treat any number as illustrative, not universal.

Strong answer direction: use a durable membership source of truth plus a version or snapshot attached to the accepted message. What interviewer is testing: race-condition reasoning. Read deeper: Group Membership Consistency.

• What if a user is removed during fan-out? — Apply the chosen membership snapshot semantics consistently.

Strong answer direction: compare workload shape, append rate, ordered range reads, and operational scale rather than parroting a vendor. What interviewer is testing: storage judgment. Read deeper: Message Storage & Partitioning and Messaging Storage Choice.

• Why not one unbounded conversation partition? — Because long-lived or hot conversations eventually create unhealthy physical partitions.

Strong answer direction: state it explicitly; a common answer is conversation log as source of truth plus sync or delivery indexes. What interviewer is testing: architectural boundary clarity. Read deeper: Conversation Log vs Inbox.

• How do you paginate history? — Start from newest bucket and page backward by sequence or time bounds.

Strong answer direction: derive from heartbeat-backed leases across active sessions, then expose a privacy-aware aggregate. What interviewer is testing: whether you separate ephemeral state from durable history. Read deeper: Presence Architecture.

• Why TTL instead of exact global updates? — Because approximate freshness is much cheaper and sufficient.

Strong answer direction: they are short-lived hints with no durable business value after they expire. What interviewer is testing: prioritization under load. Read deeper: Typing Indicators.

• Would you ever store typing events? — Normally no; at most transiently for very short TTL handling.

Strong answer direction: large uploads would block the low-latency message lane and distort storage behavior. What interviewer is testing: workload separation thinking. Read deeper: Media Message Architecture.

• How do you authorize download? — Issue an authorized object or CDN fetch path tied to the message or media reference policy.

Strong answer direction: clients may encrypt media before upload and exchange references or keys through the message path. What interviewer is testing: architecture-level crypto impact, not protocol memorization. Read deeper: End-to-End Encryption Impact.

• What if the CDN is down? — Text chat can continue while media fetch degrades.

Strong answer direction: define the boundary explicitly; it may power async fan-out or notifications without being required for sender ACK of 1:1 chat. What interviewer is testing: dependency-boundary clarity. Read deeper: Event Stream / Kafka Role.

• What if Kafka goes down? — Only Kafka-dependent workflows degrade; accepted message correctness still needs a durable async handoff strategy.

Strong answer direction: use a transactional outbox or other durable handoff pattern. What interviewer is testing: async correctness beyond the happy path. Read deeper: Event Stream / Kafka Role.

• Is producer buffering enough? — No—in-memory buffers are not durable outage recovery.

Strong answer direction: start with one conversation home region or current write authority, then replicate or deliver cross-region. What interviewer is testing: ordering under geography. Read deeper: Multi-Region Messaging.

• Why not active-active everywhere? — Because ordering, partition behavior, and split-brain risk become much harder.

Strong answer direction: one authority at a time with leases, fencing, or stronger consensus depending on requirements. What interviewer is testing: regional correctness, not just replication vocabulary. Read deeper: Multi-Region Split-Brain / Dual Writer.

• What RPO/RTO would you state? — Be explicit; do not promise magic failover windows without qualification.

Strong answer direction: clients reconnect with jitter, routes repopulate, and durable state plus sync close any missed-delivery gap. What interviewer is testing: recovery-path fluency. Read deeper: Connection Gateway Failure.

• How do you prevent the reconnect storm from becoming the next outage? — Admission control, staged recovery, and pre-provisioned headroom.

Strong answer direction: one logical message, Alice retries with same client ID, Bob laptop may already have the message, Bob phone later recovers it via sync cursor, and delivery semantics remain explicit. What interviewer is testing: can you narrate the core distributed protocol end-to-end. Read deeper: Message Idempotency, Offline Message Sync, and ACK Lost After Durable Write.

• What if the laptop got the same message twice? — Device deduplicates on stable server message ID.

Strong answer direction: push delay affects wake-up latency for the offline phone, not whether the message exists. What interviewer is testing: source-of-truth discipline. Read deeper: Offline Push Notifications and Push Provider Outage.

• Would Alice's ACK change because push failed? — No; sender ACK is about durable acceptance, not notification success.