Complete Frontend System Design Guide
Table of Contentsβ
1. Prerequisitesβ
1.1 JavaScript Internalsβ
Event Loop
- Call stack, task queue, microtask queue
- Promise resolution order
setTimeoutvsPromise.then
Closures
- Lexical scoping
- Module pattern
- Memory implications
Prototypal Inheritance
- Prototype chain
__proto__vsprototype- Constructor functions vs classes
Async Patterns
- Callbacks, Promises, async/await
- Error handling in async code
- Race conditions
Memory Leaks
- Event listener cleanup
- Closures holding references
- Detached DOM nodes
1.2 Browser Fundamentalsβ
Rendering Pipeline
- Parse HTML β DOM tree
- Parse CSS β CSSOM tree
- Combine β Render tree
- Layout (reflow)
- Paint
- Composite layers
Reflow vs Repaint
- Reflow: Geometry changes (expensive)
- Repaint: Visual changes (cheaper)
- Composite: GPU-accelerated (cheapest)
Critical Rendering Path
- Blocking vs non-blocking resources
- Async vs defer scripts
- CSS render blocking
1.3 React Internalsβ
Reconciliation
- Virtual DOM diffing
- Keys importance
- Fiber architecture
Hooks Lifecycle
- Mounting, updating, unmounting phases
- Effect cleanup functions
- Dependency arrays
Controlled vs Uncontrolled
- Single source of truth
- Performance implications
- Use cases for each
2. Requirements Explorationβ
2.1 Functional Requirementsβ
Define what the system must do:
- User actions (CRUD operations)
- Business logic
- Features and capabilities
- User workflows
2.2 Non-Functional Requirementsβ
Define how the system should perform:
- Performance (load time, FPS)
- Scalability (user count, data volume)
- Availability (uptime, offline support)
- Security (auth, data protection)
- Accessibility (WCAG compliance)
- Browser support
- Mobile responsiveness
2.3 Scoping Questions Frameworkβ
Users & Context
- Who are the primary users?
- What devices/browsers?
- Geographic distribution?
- Network conditions?
Scale & Performance
- Expected user count?
- Peak traffic patterns?
- Data volume?
- Performance targets (TTI < 3s, FCP < 1.5s)?
Features & Constraints
- Core features vs nice-to-have?
- Real-time requirements?
- Offline support needed?
- Integration points?
Business & Technical
- Time to market?
- Team size/structure?
- Legacy system constraints?
- Budget considerations?
3. High-Level Architectureβ
3.1 Monolith SPAβ
When to use:
- Small to medium applications
- Single team
- Unified user experience
Structure:
src/
βββ features/
β βββ auth/
β βββ dashboard/
β βββ settings/
βββ shared/
β βββ components/
β βββ hooks/
β βββ utils/
βββ app/
Pros:
- Simple deployment
- Easier state sharing
- Lower initial complexity
Cons:
- Harder to scale teams
- All-or-nothing deploys
- Monolithic bundle
3.2 Modular Monolithβ
When to use:
- Growing applications
- Multiple feature teams
- Need clear boundaries
Structure:
packages/
βββ auth-module/
βββ orders-module/
βββ payments-module/
βββ shared-ui/
Pros:
- Clear module boundaries
- Incremental migration path
- Still simpler than micro frontends
Cons:
- Requires discipline
- Shared dependencies management