Solution Pack: Production SaaS Dashboard
What this solution demonstrates
This solution pack shows what a strong answer to capstone-production-saas-dashboard looks like. It is not the only valid architecture. It is a calibrated example of decision quality, artifact depth, and review evidence.
Architecture summary
Decision: build a modular frontend monolith with feature-owned slices, a shared platform layer, a governed design system, server/BFF-owned data contracts, URL-owned shareable state, and route-specific rendering strategies. Avoid microfrontends until team/release independence creates enough value to justify operational cost.
Route rendering matrix
| Route | Strategy | Data owner | Client interactivity | Budget focus |
|---|---|---|---|---|
/login | static or SSR shell | auth service | minimal | LCP and security headers |
/dashboard | server shell with streamed/panel data | BFF | dashboard cards and notification island | LCP, panel failures |
/customers/:id | server composition with client tabs | customer BFF | tabs, notes, related records | data freshness and authorization |
/orders | hybrid shell plus client-heavy table | order search API | filters, table, saved views | INP and stale response ordering |
/exports/:jobId | server shell plus polling/SSE island | export service | progress, cancel, retry | reliability and idempotency |
State ownership
| State | Location | Reason |
|---|---|---|
| tenant and role context | server session/BFF response | authorization cannot rely on browser state |
| filters and search params | URL | shareable, restorable, support-debuggable |
| server data | query/cache layer bound to BFF contracts | freshness and invalidation are server-aware |
| table selection | component or feature store | transient interaction |
| export job | server | side-effecting workflow and audit |
| notification read/unread optimistic state | client overlay plus server reconciliation | responsive UX with correction path |
| user density preference | preference store | cross-session UI setting |
ADR bundle
ADR 1: Modular monolith over microfrontends
Context: multiple teams ship into one dashboard, but they share release, design system, auth/session, and route shell.
Decision: use feature-owned modules inside one deployable frontend. Enforce boundaries with import rules and ownership. Revisit microfrontends only when independent deployment, runtime isolation, or organizational boundaries outweigh shared-platform simplicity.
Consequences:
- simpler observability and release coordination
- lower runtime integration cost
- requires strong module governance
- fewer independent team deployments
Verification:
- boundary violation count
- feature lead time
- cross-feature import exceptions
- dashboard release incident rate
ADR 2: URL state for shareable filters
Context: support and finance users share filtered views and support needs reproducible bug reports.
Decision: filters, pagination, and stable sort state live in URL. Transient table UI remains local.
Consequences:
- better shareability and debugging
- longer URLs for complex filters
- requires validation of obsolete/invalid query params
Verification:
- invalid query param handling tests
- support reproduction success
- stale response ordering tests
ADR 3: Export job reliability
Context: exports can take minutes and may continue after navigation.
Decision: exports are server-owned jobs with idempotency keys, progress status, cancellation, retry, and notification on completion.
Consequences:
- reliable side effects
- more backend workflow complexity
- clearer support/debugging path
Verification:
- duplicate submit test
- timeout and retry test
- job status telemetry
- cancellation audit event
Failure matrix
| Failure | UX | Architecture control | Signal |
|---|---|---|---|
| dashboard panel API timeout | panel error, rest of page usable | panel-level boundaries | panel error rate |
| stale response after rapid filters | latest filter result wins | abort/sequence requests | stale overwrite test |
| permissions change mid-session | protected actions fail closed | server authorization and session refresh | authorization denial metric |
| export job fails | retryable job state | idempotency and job tracking | export failure rate |
| notification optimistic update rejected | local state reconciles | server acknowledgement | reconciliation count |
| large table causes INP regression | table remains responsive | virtualization or pagination budget | p75 INP by table route |
Quality gates
| Gate | Evidence |
|---|---|
| Performance | route budgets, Web Vitals/RUM dashboard, trace for table interaction |
| Accessibility | keyboard walkthrough for filters, table, dialogs, notifications |
| Security | server authorization proof, sensitive telemetry review |
| Reliability | panel degradation matrix and export idempotency tests |
| Observability | release, route, tenant class, experiment, trace id correlation |
| Ownership | feature owner map and exception register |
Launch plan
- Internal dogfood for dashboard and customer detail.
- Beta tenant cohort for dashboard home and order search.
- Export workflow behind separate flag.
- Notifications optimistic state behind role-limited flag.
- Review RUM, errors, accessibility findings, and support tickets weekly during beta.
- Promote to GA only after quality scorecard is green/yellow with owners for all yellow rows.
Portfolio summary
This capstone demonstrates architecture breadth: route rendering, data contracts, state ownership, modular boundaries, performance budgets, accessibility gates, security posture, export reliability, observability, and governance. A strong portfolio submission should include the diagrams, ADRs, failure matrix, budget table, review packet, and launch scorecard.