Design Rich Message Formatting

Medium50 min
1 / 30
understanding8 min read

Problem Scope and Product Goals

How Problem Scope and Product Goals (understanding) informs Rich Message Formatting architecture and interviewer depth.

Problem Scope and Product Goals

Rich message formatting introduces a distributed contract problem: clients author structured content, backend policy services validate it, and rendering paths must reproduce identical output across web, mobile, and notification surfaces. This section defines invariants for authoring, persistence, and rendering so interviews stay concrete and implementation-ready.

We enforce deterministic normalization, bounded render budgets, and policy-driven sanitization to block script injection, malformed nesting, and denial-of-service style payloads. We also track a strict compatibility matrix so older clients can safely degrade unsupported blocks into canonical plaintext fallbacks without data loss.

Architecture decisions are expressed with measurable SLO impact, data model implications, and migration paths that keep deployment risk low while teams ship new formatting primitives rapidly.

Operational details

  • Define ownership boundaries between composer, validator, renderer, and delivery services.
  • Capture idempotency for retries and deduplication in event-driven render pipelines.
  • Instrument policy rejects and render fallbacks with error taxonomy labels.

Why interviewers care

Rich Message Formatting 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 cross-user XSS through formatting. A user crafts a message whose markup, if rendered naively, injects executable script that runs on every recipient's client — stealing tokens or hijacking sessions across the whole conversation. The fix is the spine of the design: never store or render raw HTML, never trust input. Parse and sanitize the message once on write into a canonical structured model — an allowlist of safe entities like bold, code, mention, and link with character ranges — store that as the source of truth, and have each client render natively from the safe model rather than injecting markup. State the structured-and-sanitized representation up front, because rich formatting is fundamentally a safety problem wearing a typography costume, and the disaster it must prevent is one user's text executing on another's screen.

Key Highlights

  • Lock invariants for Problem Scope and Product Goals.
  • Tie design choices to measurable SLO and cost impact.
  • Document compatibility and migration behavior explicitly.
  • Design with abuse prevention and graceful degradation.
Interview framing
Lead with user-visible behavior, then map to contracts, then discuss failure semantics.
Avoid this
Do not treat rich formatting as untrusted HTML; persist typed AST plus policy metadata.

Section Rescue Kit

Buzzwords to use:

AST NormalizationRender Budget

Safe statements:

  • "Let me anchor this choice to latency, safety, and compatibility impact."
  • "I can offer a cheaper fallback if interviewer prioritizes cost over flexibility."
Design Rich Message Formatting - System Design | WinJob | WinJob