Reference Architecture: SaaS Dashboard
Product forces
SaaS dashboards usually optimize for authenticated productivity, dense data, permissions, reliable mutations, and repeated daily use.
Architecture sketch
Default decisions
| Area | Default |
|---|---|
| rendering | server-rendered or static shell plus client-heavy authenticated workspace |
| state | server state in query cache, URL state for filters, local state for panels |
| API | BFF or aggregation layer for dashboard-specific joins |
| permissions | route guard plus action-level authorization checks from server |
| performance | route budgets by workspace, virtualized lists, deferred charts |
| reliability | partial data states and per-widget degradation |
| observability | route, widget, API, permission, and mutation signals |
Critical risks
- Unbounded global state coupling across features.
- Permission assumptions cached too broadly.
- Data-heavy views without virtualization or pagination.
- "One dashboard route" that becomes a product monolith.
- Observability that cannot isolate widget/API failures.
Review checklist
- Does each workspace route have an owner and rendering strategy?
- Are filters and pagination encoded in URL where users expect shareability?
- Can each widget fail independently?
- Are permissions enforced server-side, not only hidden client-side?
- Are data tables accessible by keyboard and screen reader users?
Exercises
- Draw a route inventory for a SaaS dashboard.
- Define the state ownership model for filters, selected rows, permissions, and user profile.
- Create a failure matrix for three widgets on one route.
Source lens
Pair this with the production SaaS dashboard capstone and the worked system-design answer.