Design Message Forwarding

Problem Statement And User Promise

Message forwarding looks simple in UI, but backend behavior must preserve correctness under retries, edits, deletes, and multi-device sync. This section focuses on concrete contracts and operational guarantees for block 1.

Interview framing

In interviews, I state the user promise first: forwarding should be fast, preserve attribution, avoid duplicate sends, and respect recipient privacy and policy. Then I anchor decisions on measurable SLOs and explicit consistency boundaries.

Design commitments

• Forward action ACK latency target: p95 below 220 ms in the active region.
• End-to-end recipient fan-out latency target: p99 below 2.5 s for large groups.
• Exactly-once user-visible delivery illusion via idempotent write pipeline and dedupe keys.
• Traceable lineage for abuse investigation and legal hold obligations.

Failure posture

The forwarding pipeline treats each downstream recipient write as independently retriable. If one shard stalls, unaffected shards continue. The client receives a partial-progress model backed by reconciliation events instead of silent failures.

Why this matters

Forwarding is frequently used for urgent updates, support escalations, and incident communication. If the architecture allows duplicate forwards or missing attribution, trust erodes quickly and moderation cost increases.

Operator visibility

I expose per-stage metrics: api_ack_ms, dedupe_hit_rate, queue_backlog_depth, write_error_rate, and per-region fanout_slo_breaches. On-call can isolate whether issues are ingress, queue, or persistence related in minutes.

Scope guard

This section keeps media transcoding out of path because forwarding should reuse immutable media references. That choice isolates latency-sensitive metadata writes from heavy binary workloads.

Why interviewers care

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

The failure that defines the design

The outage to narrate is the forward storm. One tap forwards a message to two hundred groups, each a fan-out to thousands of members, and because forwards can be re-forwarded, a single viral message spreads exponentially — the mechanism behind real-world misinformation cascades. The fix is structural and is the spine of the design: a forward is not an unbounded broadcast but a bounded create-N operation, capped at a forward limit (a small maximum of chats per action), carrying a hop-count that increments on each re-forward so highly-forwarded messages can be labeled and re-forwarding curtailed. State the forward-limit and hop-count up front, because forwarding's defining risk is amplification, and the design's job is to make resharing easy while keeping the blast radius bounded.