Capstone: Production SaaS Dashboard Architecture

Product scenario

Design the frontend architecture for a multi-tenant SaaS operations dashboard used by support, finance, and account managers. The product includes a public login route, authenticated workspace shell, dashboard home, customer detail page, order history, saved filters, export workflow, notifications, and role-based feature access.

The architecture must support multiple teams shipping into the same application without turning the codebase into a shared-global-components folder.

Functional requirements

• Authenticated workspace with tenant and role context.
• Dashboard cards with mixed freshness needs.
• Customer detail route with server-owned data and client-side interaction.
• Search and filter experience with shareable URL state.
• Export workflow with progress, cancellation, and error states.
• Notification center and optimistic read/unread state.
• Admin-only routes and feature-flagged surfaces.

Non-functional requirements

Concern	Requirement
Performance	p75 LCP under 2.5s for dashboard home; p75 INP under 200ms for filters and table actions.
Reliability	Partial API failures must degrade individual panels, not the whole app.
Security	Authorization is enforced server-side; frontend role checks are visibility hints only.
Accessibility	Keyboard and screen-reader workflows must work for filters, tables, dialogs, and notifications.
Observability	Route, tenant class, release, experiment, and error context must be captured.

Architecture constraints

• Route-level rendering decisions must be explicit.
• Client state, server state, URL state, and form state must not be collapsed into one store.
• Shared utilities must have ownership and dependency rules.
• Critical interactions must have measured performance budgets.

Required diagrams

• System context diagram.
• Route rendering matrix.
• Feature-sliced module map.
• Data ownership and cache-layer diagram.
• Observability signal flow.

Sample system context diagram

Sample route rendering matrix

Route	Strategy	Data owner	Cache policy	Hydration budget
/login	SSR or static shell	Auth service	no-store for auth callbacks	minimal
/dashboard	server shell plus client panels	BFF	short-lived route data, panel-level refetch	shell plus interactive panels
/customers/:id	SSR or RSC-style composition	Customer service through BFF	role/tenant keyed	detail tabs hydrate on demand
/orders	client-heavy workspace	Order service through query API	URL state plus server state cache	table/filter budgeted
/exports/:jobId	server shell plus polling/SSE island	Export service	job state no-store	progress island only

Sample feature-sliced module map

Implementation milestones

1. Define personas, workflows, and route inventory.
2. Create route rendering strategy for login, dashboard, detail, search, and export.
3. Design API/BFF contracts and cache invalidation rules.
4. Define feature boundaries and dependency policy.
5. Specify design-system primitives needed by tables, dialogs, filters, and notifications.
6. Add performance budgets and measurement plan.
7. Add security, reliability, and accessibility launch gates.
8. Write final review packet and portfolio summary.

ADRs to write

• ADR: Rendering strategy for authenticated dashboard routes.
• ADR: Server state, URL state, and client interaction state ownership.
• ADR: Feature module boundaries and shared utility governance.
• ADR: Export workflow reliability and progress model.

Gates

Gate	Evidence
Performance	Route budget table, profile for filter interaction, bundle/request inventory.
Security	Auth/session model, role-check explanation, sensitive-data handling notes.
Accessibility	Keyboard walkthrough for table, filter, dialog, and notification flows.
Reliability	Partial failure matrix and degraded UI states.
Observability	Event/error/Web Vitals schema with owner and retention notes.

Failure-mode review

• Dashboard panel API timeout.
• Saved filter contains invalid or obsolete query params.
• Tenant permissions change during active session.
• Export job fails after user navigates away.
• Feature flag enables a route for the wrong cohort.
• Large table causes INP regression.

Architecture drills

Drill	Expected architect-level answer	Common weak answer
A dashboard panel API becomes unreliable during peak hours.	Isolate panel failure, preserve shell usability, add timeout/retry/degraded copy, trace by route/panel/release, define owner and rollback.	Add a spinner and retry forever.
A team wants one global store for filters, permissions, notifications, and table state.	Split URL/server/local/global shell state, document ownership and invalidation, keep cross-feature state narrow.	Pick the most popular state library.
Table interactions regress INP after adding bulk actions.	Profile interaction, reduce render scope, virtualize, defer non-critical work, gate with INP budget and feature flag.	Memoize everything without measuring.

Final review rubric

Use rubrics/frontend-architect-rubric. Passing requires level 4 evidence for rendering/data architecture, performance diagnosis, reliability/security/accessibility, and written communication.

Portfolio deliverables

• Architecture overview.
• Diagrams.
• ADR bundle.
• Route rendering matrix.
• NFR scorecard.
• Launch review packet.
• Post-launch monitoring plan.

Completed artifact targets

By the end, the capstone should include:

• one completed ADR using the style in part-xii/completed-examples/completed-adr-examples
• one completed architecture review using review-packets/rendering-data-review-packet
• one performance budget using part-xii/completed-examples/completed-performance-budget-example
• one security note using part-xii/completed-examples/completed-threat-model-example

Use capstone-solution-pack-production-saas-dashboard as a calibrated example of a strong final answer.