Angular system-design challenge

Attempt this only after the production architecture lesson. Make the learner clarify and choose; do not provide the dimension prompts until an initial design exists. Change at least one constraint on repeat attempts so memorized architecture cannot count as mastery.

Scenario: enterprise learning platform

Design an Angular frontend for candidates, interviewers, and administrators. It supports question banks, live interview notes, scheduling, offline draft recovery, role-based views, audit history, and 100k monthly users.

Clarify first

Ask about SEO, authenticated/public split, latency regions, offline guarantees, collaboration consistency, accessibility target, browser support, team topology, release independence, backend contracts, and regulated/sensitive data.

Cover these dimensions

Boundaries

Map routes to business capabilities. Keep transport DTO mapping, domain state, and presentation distinct where they change independently. Do not propose micro-frontends until deployment/team constraints require them.

State

Classify server cache, URL state, persisted draft, cross-route workflow state, and ephemeral component state. Name owner and lifetime for each. Explain invalidation and conflict behavior.

Rendering

Choose CSR/SSR/SSG per route. Public job/content pages may benefit from SSR/SSG; authenticated dashboards may prioritize CSR while still using SSR for startup. Address hydration-safe browser APIs.

Data and failure

Discuss typed contracts plus runtime validation, cancellation, retries with idempotency, optimistic concurrency, offline queueing, and observable error reporting.

Security

Backend authorization is authoritative. Discuss XSS-safe rendering, token/session strategy with the backend, CSRF implications, CSP, dependency hygiene, and redacted telemetry. Never place secrets in Angular builds.

Quality

Propose contract tests, focused component/domain integration, a few critical E2E flows, accessibility automation plus manual keyboard/screen-reader checks, performance budgets, and production monitoring.

Follow-up pressure tests

• Two tabs edit the same draft.
• A deploy changes DTO shape while old clients remain open.
• A lazy chunk fails after deployment.
• A screen reader user joins the live session.
• Network drops during save.
• One feature team needs independent releases.

Evaluation

A strong design is conditional, incremental, and operational. It connects Angular mechanisms to product constraints. A weak design lists libraries without ownership, lifetime, failure, security, or migration reasoning.