The RADIO Framework

Requirements • Architecture • Data Model • Interfaces • Optimisations

RADIO is a lightweight mental model for dissecting any frontend system-design question. It keeps you organised, ensures you cover the fundamentals, and—most importantly—helps the interview panel follow your logic.

Framework Snapshot

Each layer informs the next—skipping one usually surfaces as a blind spot later.

1. Requirements

Goal: Prove you understand what you are building and why it matters.

Questions to Ask

1. Primary user journeys—what must the first release enable?
2. Supported environments—desktop, mobile, PWA, low-bandwidth?
3. Non-functional constraints—latency budgets, offline tolerance, accessibility standards, localisation requirements.

Deliverables

• Clear, written problem statement.
• List of functional versus non-functional requirements.
• Agreed-upon out-of-scope items to prevent later surprises.

Spend ~10 % of the interview here; a shaky foundation infects the rest of your answer.

2. Architecture

Goal: Show how you will arrange code and runtime pieces so the product can evolve safely.

Design Axes

Deliverables include a block-diagram and a 30-second elevator pitch that ties choices back to requirements.

3. Data Model

Goal: Capture the entities, relationships, and lifecycle rules that drive the UI.

Process

1. Identify entities. Example for a blog: User, Post, Comment, Reaction.
2. Define attributes and types. Include version fields when concurrent edits matter.
3. Map relationships. One-to-many (User → Post), many-to-many (Post ↔ Tag).
4. Choose normalisation level. Flat lists for virtualised UIs; denormalised blobs for read-heavy dashboards.

Why Interviewers Care

• A sound model prevents duplicated state, expensive joins, and brittle caches.
• It demonstrates foresight on pagination, search, and real-time updates.

4. Interfaces

Goal: Document how modules and services talk—because most production bugs hide at the seams.

Surface Areas to Cover

1. HTTP / GraphQL API. Verb semantics, batching rules, pagination, optimistic mutation format.
2. Real-time channels. WebSocket event schemas, reconnect policy, back-pressure handling.
3. Error taxonomy. Distinguish retryable network failures from user-action errors; map to UI states.
4. Versioning strategy. Contract testing, deprecation windows, feature flags.

Example REST Contract

GET /api/posts/{id}
→ 200 OK
{
"id": "42",
"title": "RADIO in Practice",
"content": "...",
"author": { "id": "7", "name": "Ada" }
}

5. Optimisations

Goal: Stress-test the design under real-world conditions and demonstrate senior-level skills.

Performance

• Code-split on route and component boundaries; measure bundle budgets in CI.
• Cache-first data fetches with stale-while-revalidate to minimise spinner time.
• Web Vitals targets—LCP < 2.5 s, CLS < 0.1—backed by RUM dashboards.

Accessibility

• Semantic HTML first; ARIA only when unavoidable.
• Contrast ratios, focus order, reduced-motion media query support.

Security

• Strict CSP and Trusted-Types against XSS.
• Short-lived JWTs stored in httpOnly, sameSite =lax cookies.
• Audit 3rd-party scripts for supply-chain risks.

Internationalisation

• Text outside code; ICU message format; layout mirroring for RTL.
• Lazy-load locale data and fonts.

Observability

• Correlate frontend IDs with backend logs via distributed tracing headers.
• Capture error boundaries and ship sourcemaps for debuggable stack traces.

Using RADIO Effectively

1. Start every interview by stating you will apply RADIO—signals structure.
2. Allocate time intentionally: 10 % requirements, 25 % architecture, 20 % data, 20 % interfaces, 20 % optimisation, 5 % recap.
3. At transitions, sign-post: “Requirements clarified; moving to architecture.”
   This keeps the panel with you and prevents premature deep dives.
4. Close with risks, next steps, and how you would validate the design in production.

Next Steps

Move on to the Requirements chapter to see RADIO’s first stage applied to a real product brief, complete with interviewer Q&A patterns and sample white-board diagrams.