18th July

Different system design interview Formats:

1️⃣ Deep Dive Into One System (End-to-End Design)

Candidate designs a full system:

• Functional requirements
• Non-functional requirements
• Architecture decisions
• Trade-offs
• Scaling strategy

Examples:

• Design Google Docs frontend
• Design Instagram feed UI
• Design Netflix homepage

Focus:

👉 breadth + depth + reasoning

2️⃣ Scenario-Driven Problem Solving

Also very common.

Interviewer gives targeted scenarios:

• Performance bottleneck
• State explosion
• Data consistency issue
• Rendering problem

Examples:

• How to render 1M rows?
• How to handle offline edits?
• How to prevent duplicate API calls?

Focus:

👉 applied problem solving

3️⃣ Debug / Improve an Existing Architecture

Candidate is given a system that already exists but has issues.

Task:

• Identify bottlenecks
• Refactor architecture
• Improve performance
• Suggest migration strategy

Examples:

• App re-renders too often
• Bundle size too large
• API layer messy
• State management broken

Focus:

👉 real-world engineering maturity

This is extremely popular in staff/principal interviews.

Topic 1: Different architectural patterns

Based on the frontend architecture.

🎯 Why Frontend Architecture Matters

As applications grow:

• More features
• More teams
• Faster releases
• Independent deployments
• Technology diversity

Without a proper architecture, projects become:

❌ tightly coupled

❌ hard to scale

❌ slow to deploy

❌ difficult to maintain

Frontend architecture defines:

How code is structured, built, owned, and deployed at scale.

1️⃣ Monolithic Frontend Architecture

What is it ?

A single frontend application containing all features, pages, and UI modules in one codebase and one build.

Everything ships together.

Structure (Typical React SPA)

src/
  components/
  pages/
  hooks/
  utils/
  services/
  store/

Single build output:

bundle.jsindex.html

How it works

One repository
↓
One build pipeline
↓
One deployment
↓
Whole app updated together

Advantages

✅ Simple to start

✅ Easy dependency management

✅ Shared state straightforward

✅ Fast local development

✅ No cross-app communication

Limitations (at scale)

❌ Large bundle size

❌ Slow builds

❌ Teams block each other

❌ Risky deployments

❌ Hard to adopt different tech stacks

❌ Code ownership unclear

Best suited for

• Small to medium apps
• Single team
• Early stage product
• Tight feature coupling

Example (Monolithic React App)

// App.jsx
import Dashboard from "./pages/Dashboard";
import Orders from "./pages/Orders";
import Profile from "./pages/Profile";

export default function App() {
  return (
    <>
      <Dashboard />
      <Orders />
      <Profile />
    </>
  );
}

All features in one runtime.

Imagine the entire Amazon website is built as one React application.

Amazon App
│
├── Home
├── Search
├── Product Details
├── Cart
├── Checkout
├── Orders
├── Profile
└── Payments

Everything is:

• Built in one repository.
• Deployed together.
• Released together.
• Owned by one frontend team.

2️⃣ Micro-frontend Architecture

What is it?

Frontend split into multiple independent applications, each owned by different teams and deployed separately.

Like microservices — but for UI.

Each feature is its own app.

Conceptual Structure

Shell 
/Container App
   ├── Auth App
   ├── Dashboard App
   ├── Orders App
   └── Profile App

Each micro app:

• independent repo (sometimes)
• independent deployment
• independent build

How it works

Browser loads shell app
↓
Shell dynamically loads micro apps
↓
Each app renders its part of UI

Advantages

✅ Independent team ownership

✅ Independent deployment

✅ Smaller codebases

✅ Technology flexibility

✅ Faster scaling of organization

Challenges

❌ Shared state complexity

❌ Cross-app communication

❌ Version compatibility

❌ Performance overhead

❌ Operational complexity

Best suited for

• Large organizations
• Multiple teams
• Domain-based ownership
• Frequent independent releases

3️⃣ Microfrontend Implementation Techniques

There are several ways to implement microfrontends.

A. Runtime Integration (Most Common)

Apps loaded dynamically at runtime.

Popular methods:

• Module Federation (Webpack)
• iframe embedding

B. Edge / Server Composition

Server assembles UI from multiple sources.

4️⃣ Basic Micro-frontend Example (Module Federation)

App Shell loads remote app

const OrdersApp = React.lazy(() => import("ordersApp/App"));

function App() {
  return (
    <Suspense fallback="Loading...">
      <OrdersApp />
    </Suspense>
  );
}

Amazon as a Micro Frontend

Instead of one large React application, each business domain owns its own frontend application.

                     Amazon
                       │
 ┌──────────┬──────────┬──────────┬──────────┬──────────┐
 │          │          │          │          │          │
Home     Search     Product     Cart     Checkout    Profile
 Team      Team      Team        Team        Team       Team
 │          │          │          │          │          │
ReactApp  ReactApp  ReactApp   ReactApp   ReactApp   ReactApp

Each team has:

• Its own repository
• Its own build pipeline
• Its own deployment pipeline
• Independent release schedule

Monorepo vs Poly-repo

These describe the Repository (Source Code) Organization.

Monorepo

A monorepo stores multiple logical projects or applications in a single Git repository.

Example

amazon-frontend/
│
├── home/
├── search/
├── cart/
├── checkout/
├── profile/
└── shared-ui/

Advantages

• Easy code sharing.
• Single source of truth.
• Simplified dependency management.
• Easier refactoring across projects.
• Consistent tooling and coding standards.

Disadvantages

• Repository becomes larger over time.
• Builds and CI/CD can become slower without proper tooling.
• Requires tools like Nx or Turborepo for efficient scaling.

Polyrepo

A polyrepo stores each application or service in its own Git repository.

Example

home-app/
search-app/
cart-app/
checkout-app/
profile-app/
shared-ui/

Each repository has its own:

• Git history
• CI/CD pipeline
• Versioning
• Release cycle

Advantages

• Complete team independence.
• Smaller repositories.
• Independent deployments and releases.
• Easier access control.

Disadvantages

• Sharing common code is more difficult.
• Dependency updates must be synchronized across repositories.
• Maintaining consistency across teams requires more coordination.

Comparison

Monolithic v/s Mono repo

Key Takeaway

Monorepo is about organizing multiple projects within a single repository, whereas Polyrepo organizes each project in its own repository. The choice depends on team size, ownership, and collaboration needs.

Topic 2: Different rendering techniques

1️⃣ Client-Side Rendering (CSR)

What it is

The browser downloads a minimal HTML file and JavaScript bundle.

JavaScript runs and builds the UI in the browser.

How it works

Browser loads HTML
↓
Downloads JS bundle
↓
JS fetches data
↓
UI rendered in browser

Example

Typical React SPA built using:

• Create React App
• Vite

Example pages:

• Gmail web
• Trello
• Admin dashboards

Best suited for

✅ Highly interactive applications

✅ Logged-in dashboards

✅ Apps where SEO is not critical

✅ Frequent UI updates

Not ideal for

❌ SEO-heavy sites

❌ Slow initial load on weak devices

2️⃣ Server-Side Rendering (SSR)

What it is

HTML is generated on the server for every request and sent fully rendered to the browser.

How it works

User requests page
↓
Server fetches data
↓
Server renders HTML
↓
Browser receives ready page
↓
JS hydrates for interactivity

Example

Next.js :

Common sites:

• E-commerce product pages
• News websites

Best suited for

✅ SEO critical pages

✅ Faster first content display

✅ Dynamic data per request

✅ Social media preview support

Not ideal for

❌ Very high traffic with heavy rendering cost

❌ Purely static content

Here is why SSR is better in rendering compared to CSR

CSR

Request Page
      │
      ▼
Receives

<html>
  <div id="root"></div>
  <script src="bundle.js"></script>
</html>

At this point, the page contains almost no meaningful content.

SEO Bot now has to:

1. Download the JavaScript.
2. Execute the JavaScript.
3. Wait for API calls.
4. Render the page.
5. Extract the content.

SSR

Request Page
      │
      ▼
Receives

<h1>React Interview Questions</h1>

<p>Learn React Hooks...</p>

<img .../>

Everything is already present in the initial HTML.

SEO Bot can immediately:

• Read the headings.
• Read the text.
• Discover links.
• Index the page.

3️⃣ Static Site Generation (SSG)

What it is

HTML pages are generated at build time and served as static files.

How it works

Buildtime: Generate HTML for all pages.
Runtime: Serve pre-built HTML instantly.

Example

Common sites:

• Blogs
• Documentation
• Marketing pages

Best suited for

✅ Content rarely changes

✅ Maximum performance

✅ SEO important

✅ CDN delivery

Not ideal for

❌ Frequently changing data

❌ Personalized content

4️⃣ Incremental Static Regeneration (ISR)

What it is

Hybrid of SSG + SSR.

Static pages are regenerated periodically after deployment.

How it works

User visits page
↓
Gets cached static version
↓
Background regeneration after interval
↓
Next user gets updated page

Example

Common use:

• Product catalogs
• Blog lists
• News feeds updating periodically

Best suited for

✅ Mostly static but occasionally updated content

✅ High traffic pages

✅ SEO required with freshness

Topic 3: Authorization Models in UI

(RBAC, ABAC, Feature-Level Access Control)

What is Authorization in the UI?

Authorization determines what a user is allowed to see or do in the frontend based on permissions.

Important distinction:

Frontend authorization is primarily about:

• Controlling visibility
• Preventing accidental access
• Improving UX

⚠️ Security must still be enforced on the backend.

Role-Based Access Control (RBAC)

Users are assigned roles, and roles have permissions.

Example roles:

• Admin
• Manager
• User

Example UI behavior:

Admin → Can see user management 
page User → Cannot see admin panel

Typical frontend implementation

• Role stored in auth state
• Route guards
• Conditional rendering

Example:

if (user.role ==="admin") {
		return <AdminPanel />;
}

Advantages

• Simple mental model
• Easy to implement
• Works well for most apps

Limitations

• Rigid
• Hard to handle complex rules
• Role explosion in large systems

Attribute-Based Access Control (ABAC)

Access depends on attributes, not just roles.

Attributes can include:

• User properties
• Resource properties
• Context (time, location, ownership)

Example rules:

User can edit document

if:
- user.id === document.ownerId AND document.status !== "locked"

Why ABAC is powerful

• Flexible
• Fine-grained control
• Context-aware decisions

Why ABAC is harder

• More logic
• More evaluation rules
• Harder debugging

Feature-Level Access Control (who can access the feature)

Controls access to specific features, not just pages.

Examples:

• Premium feature enabled only for paid users
• Beta feature for selected accounts
• Permission to export data

Implementation styles:

• Feature permission matrix.
• Feature flags tied to user entitlements.
• Backend-provided capability list

Example:

user.permissions = ["EXPORT_DATA","VIEW_ANALYTICS"]

How these models are used together (real systems)

Typical enterprise flow:

Authentication → user identity
↓
RBAC → coarse control
↓
ABAC → fine control
↓
Feature flags → rollout control

System Design Considerations

• UI must never be the source of truth
• Backend returns permission metadata
• UI renders based on capabilities, not roles directly
• Permissions should be cacheable
• Must support dynamic updates

Topic 4: Feature Flags & Remote Configuration Architecture

Whether feature is enabled or not

What are Feature Flags?

Mechanism to enable or disable functionality without deploying code.

Why Feature Flags Exist

• Gradual rollout
• A/B testing
• Kill switch
• Environment targeting
• Premium features

Types of Feature Flags

Remote Configuration

Feature state stored on remote server.

Client fetches configuration at runtime.

Example config:

{"newDashboard":true, "maxUploadSize":10, "betaFeatures":["aiAssistant"]}

Evaluation Strategy

Client decides:

if (featureEnabled) render component 
else render fallback

Evaluation may depend on:

• user id
• region
• device
• plan
• experiment bucket

System Design Flow

App starts
↓
Fetch config service
↓
Cache locally
↓
Evaluate flags per user
↓
Render UI

Key Design Concerns

• Startup latency
• Offline fallback
• Config caching
• Versioning
• Safe defaults
• Rollback strategy

Why Feature Flags are critical at scale

• Reduce deployment risk
• Enable experimentation
• Enable progressive delivery
• Allow runtime control

Topic 6: Discussing practical questions

Question 1: Rapid Route Navigation While Data Fetching Is In Progress

How do you cancel, prioritize, or reuse requests efficiently?

Problem Context

User navigates quickly between routes:

/products → /cart → /profile → /orders

Each route triggers API calls.

Problems that can happen:

• Old requests finish after navigation → stale UI renders
• Unnecessary network load
• Memory leaks
• Race conditions
• UI flicker
• Duplicate fetches

System Design Goals

• Cancel irrelevant requests
• Prevent stale updates
• Reuse already fetched data
• Maintain responsive UX

Meaningful Solution Architecture

✅ 1. Request Cancellation (Mandatory)

Cancel requests when component unmounts or route changes.

Use:

• AbortController (fetch)
• axios cancel token
• React Query auto-cancel

Prevents:

Old response over writing new state

✅ 2. Request De-duplication / Caching

If user revisits route quickly:

Reuse existing response

Use data layer:

• React Query
• SWR (stale-while-revalidate)
• custom cache map

Key idea:

queryKey = route + params

✅ 3. Stale Response Protection (Critical)

Even if cancellation fails, ignore outdated responses.

Technique:

• request Id tracking
• latest-only rendering

Interview Summary Answer

Cancel in-flight requests on navigation, prevent stale updates with request identity tracking, reuse cached responses via query keys, and prioritize active route data using a centralized data-fetching layer.

Question 2: Feature Flag Changes While App Is Running

How to update UI safely without breaking state or flows?

Problem Context

Feature flags are updated remotely.

User currently:

• filling form
• in checkout
• mid transaction
• editing document

Flag toggles:

feature ON → OFF

Risk:

• UI disappears mid flow
• component unmount crash
• state invalidation
• inconsistent experience

System Design Goals

• Safe rollout
• No abrupt UI removal
• State preservation
• Predictable transitions

Meaningful Solution Architecture

✅ 1. Flag Evaluation Boundary

Flags evaluated at feature entry points, not deeply inside components.

Example:

• route level
• layout level
• feature wrapper

Prevents sudden mid-tree changes.

✅ 2. Sticky Session Flags

User keeps same flag state during session.

Flag updates apply:

• next session
• next navigation
• safe checkpoint

Ensures UI consistency.

✅ 3. Graceful Degradation

If feature disabled mid-use:

• allow completion
• block new entry
• show informational message

3️⃣ Multiple Tabs — Logout In One Tab

How to synchronize session state across tabs instantly?

Problem Context

User logged in multiple tabs.

Logs out in one tab.

Other tabs still think user is authenticated.

Security risk.

System Design Goals

• Instant logout everywhere
• No refresh required
• Consistent auth state

Meaningful Solution Architecture

✅ 1. Cross-tab Communication Channel

Use browser mechanisms:

Primary options:

• storage event (localStorage change)
• BroadcastChannel API

✅ 2. Logout Broadcast Event (allows scripts from the same origin to send messages to each other across different browser contexts.)

(Think of it as a simple redux action dispatch)

On logout:

clear tokens
emit logout signal

Other tabs listen → auto logout.

✅ 3. Defensive Server Validation

Even if UI fails:

API should reject invalid token.

Interview Summary Answer

Broadcast logout events across tabs using browser communication channels like BroadcastChannel or storage events, and ensure auth state is derived from shared storage so all tabs react immediately.

4️⃣ Upgrade Banking App v1 → v2 Without Breaking Ongoing Transactions

Problem Context

Users actively performing:

• transfers
• payments
• verification flows

System must upgrade UI or API version.

Risk:

• inconsistent workflow
• request schema mismatch
• transaction corruption

System Design Goals

• Zero disruption
• Version compatibility
• Safe migration

Meaningful Solution Architecture

✅ 1. Versioned Frontend Bundles

Users continue running version they started with.

Deployment does not force reload.

✅ 2. Backward-Compatible APIs

Backend supports:

v1 contract
v2 contract

Simultaneously.

✅ 3. Session-Based Version Locking

User session tagged with version:

sessionVersion = v1

All requests routed accordingly.

✅ 4. Graceful Upgrade Trigger

Upgrade occurs only when:

• page reload
• session restart
• safe checkpoint

✅ 5. Transaction Isolation

Critical operations must not depend on UI version change.

Server remains source of truth.

Interview Summary Answer

Use versioned frontend bundles, maintain backward-compatible APIs, lock user sessions to a version during active flows, and upgrade only at safe checkpoints like reload or session restart.