Part III Rendering and Data Map
Why this page matters
Rendering and data decisions determine how users receive pixels, how fresh the UI is, where state lives, and how failure appears. This map shows the system shape before individual chapters go deep.
Rendering and data flow
Decisions this part supports
| Decision | Artifact |
|---|---|
| route rendering mode | route rendering matrix |
| hydration scope | island/client boundary map |
| server/client split | boundary ADR |
| data ownership | data ownership map |
| cache strategy | cache policy and invalidation table |
| mutation consistency | optimistic/pessimistic action policy |
Review checklist
- Is rendering chosen per route or segment rather than globally?
- Is hydration scoped to actual interaction needs?
- Is each important state value assigned to URL, local, server, or global ownership?
- Are cache invalidation and stale states explicit?
- Are API contract assumptions tested?
Exercises
- Create a route rendering matrix for your product.
- Draw a state ownership map for a complex form or dashboard.
- Write an ADR for one server/client boundary.
Source lens
Use this map before system-design interviews, SaaS dashboard, ecommerce, GenUI, and offline-first reference architectures.