Designing an e-commerce platform looks straightforward at first — show products, add to cart, checkout. But once you start building it, you quickly discover the depth behind the UI: complex state management, SEO, performance optimization, accessibility, and security all play a major role.

In this article, we’ll walk through how to design a scalable E-commerce frontend using a structured, interview-friendly approach that mirrors how modern frontend applications are actually built.

R — Requirements

In a frontend system design interview, this section sets the scope.
Strong candidates ask clarifying questions before proposing solutions.

We define both functional and non-functional requirements.

Functional Requirements

1. Product Discovery

Users should be able to:

• Browse product listings
• Search products by keyword
• Filter by category, price, rating, and brand
• Sort results (price, popularity, newest)
• View detailed product pages with images, specs, and reviews

2. Shopping Flow

Users should be able to:

• Add items to cart
• Remove items or update quantities
• Save items to a wishlist
• Apply coupons or discount codes

3. Checkout Flow

Users should be able to:

• Enter shipping and billing details
• Choose delivery options
• Select a payment method
• Place an order and see confirmation

4. User Account

Users should be able to:

• View order history
• Track order status
• Manage saved addresses and payment methods

Non-Functional Requirements

1. Internationalization (i18n / L10n)

The platform should support a global audience:

• Multiple languages
• Multiple currencies
• Region-specific pricing, taxes, and shipping rules
• Localization of dates, numbers, and addresses
• Potential right-to-left layout support

2. Offline Functionality

While checkout requires connectivity, browsing should degrade gracefully:

• Cache previously viewed product pages
• Preserve cart locally when connection drops
• Retry failed cart or checkout actions automatically once online

3. Security Considerations (XSS, CSRF)

Since payments and personal data are involved, the frontend must protect against:

• Cross-Site Scripting (XSS) from user-generated content like reviews and addresses
• Cross-Site Request Forgery (CSRF) during checkout and payment flows
• Token leakage (avoid storing auth tokens in localStorage)

4. Accessibility (a11y) Compliance

Shopping must be accessible to all users:

• Full keyboard navigation across browsing and checkout
• Screen reader compatibility
• Semantic HTML and proper ARIA roles
• Color contrast and visible focus states

5. Performance Expectations

Performance directly impacts conversion rates:

• Fast initial page load (~2–3 seconds)
• Smooth filtering, searching, and navigation
• Instant feedback for cart and checkout interactions

Additional Constraints

• Mobile-first responsive design
• SEO-optimized product pages
• Graceful handling of slow or unstable networks

C — Components

This is the heart of frontend system design.
Here we define:

• Component hierarchy (tree structure)
• State ownership
• Communication patterns
• Global vs local state decisions

In interviews, this is where most candidates win or lose.

Components Tree

Major components

State Management Strategy

The key question interviewers expect:

What lives in local state? What lives in global state? Do we need Redux?

Let’s break it down clearly.

1. Local State (Component-Level)

Use local state for UI-specific, temporary concerns.

Examples:

• Quantity selector value
• Modal open/close
• Form inputs in checkout
• Accordion expand/collapse
• Image gallery active slide

These states:

• Do not need cross-page sync
• Should not trigger global rerenders
• Stay inside their owning component

This keeps components isolated and maintainable.

2. Server State (API Data)

Products, reviews, order data — this is server state.

Recommended approach:

• Use React Query / SWR (or equivalent)
• Do NOT store server data in Redux unless necessary

Server state responsibilities:

• Fetching
• Caching
• Background refetch
• Retry logic
• Optimistic updates

Example:

• ProductListPage fetches paginated products
• ProductDetailPage fetches product by ID
• Cart validation refetches stock availability

This separates network logic from UI logic.

3. Global State (Shared Across App)

Global state should be minimal and intentional.

For E-commerce, typically:

Keep in Global Store:

• Authenticated user
• Cart items
• Cart count (for header icon)
• Theme / locale
• Selected currency
• Possibly wishlist IDs

Why cart is global?
Because:

• Cart icon in header
• Cart page
• Checkout page
• Product pages
  All depend on it.

4. Data Normalization

Products appear in multiple places:

• Search results
• Recommendations
• Wishlist
• Cart

Normalized structure:

Ensures updates remain consistent everywhere.

State Ownership Summary

Interview Tip

When explaining Components section, say:

“I minimize global state and separate server state from UI state. Most data comes from the API layer, while only cross-cutting concerns like cart and auth live globally.”

That signals senior-level thinking immediately.

A — Architecture

This section defines the key architectural decisions for an enterprise-scale e-commerce platform and why each choice is made.

1. SSR vs CSR vs SSG

Chosen: Hybrid → SSR + SSG + CSR

Why this over others

• Pure CSR hurts SEO and first paint.
• Pure SSR increases server cost and reduces interactivity.
• Pure SSG cannot handle dynamic pricing and inventory.

👉 Hybrid rendering balances SEO, scalability, and interactivity.

2. SPA vs MPA

Chosen: SPA with SSR entry points

Why this over others

• Smooth navigation (product → cart → checkout)
• Preserves session and cart state
• Better conversion due to seamless UX
• SSR still ensures SEO for public pages

Pure MPA causes full reloads and breaks flow.
Pure SPA without SSR hurts discoverability.

👉 SPA behavior + SSR routing provides the best enterprise balance.

3. REST vs GraphQL

Chosen: REST services + GraphQL API Gateway (BFF) + Mixed Pagination

Why REST for core services

• Clear mapping to microservices (products, cart, orders, payments)
• Easier HTTP & CDN caching
• Strong observability and debugging
• Scales cleanly across multiple backend teams

REST remains the internal service contract.

Q1. Why GraphQL at API Gateway (Aggregation Layer)

GraphQL is used as a Backend-for-Frontend (BFF) or API Gateway layer.

Flow:

Frontend → GraphQL Gateway → Multiple REST microservices

The gateway:

• Aggregates product, reviews, pricing, and inventory services
• Returns a single optimized response
• Reduces frontend network calls

This is especially useful for:

• Product Detail Page (multiple backend domains)
• Homepage recommendations
• Personalized feeds

Q2. Why GraphQL is valuable for mobile

• Mobile networks are slower and more expensive
• One GraphQL request reduces round trips
• Clients request only required fields
• Easier backward compatibility when mobile apps update slowly

So architecture becomes:

👉 REST internally + GraphQL gateway externally.

Best of both worlds.

4. Transport Protocol Choice (HTTP/1.1 vs HTTP/2 vs HTTP/3)

Chosen: HTTP/2 with HTTP/3 support

Why this over others

• Multiplexing improves performance on asset-heavy pages
• Header compression reduces API overhead
• HTTP/3 improves mobile resilience and connection recovery

Critical for:

• Image-heavy product pages
• Global traffic
• Mobile users

5. Communication Protocols (WebSocket, SSE, Long Polling, Short Polling)

Chosen: Primarily request-response + selective realtime

Why:

• E-commerce is mostly request-response.
• Realtime is only needed in specific flows.
• Keeps system simpler and cost-efficient.

Additional Enterprise Considerations

• CDN strategy with geo-based edge caching
• Route-based code splitting
• Lazy loading of checkout & analytics modules
• Feature flags and A/B testing support
• Optional micro-frontend architecture for domain isolation (search, cart, checkout)

D — Data Model

This section explains:

• The API contract between frontend and backend

As frontend engineers, we help define predictable and scalable APIs that match UI needs.

Endpoint Design

We follow a resource-based REST structure.

URL Strategy & Naming

Principles:

• Resource-first naming → /products, /orders
• Nest only when scoped → /products/:id/reviews
• Query params for filters & sorting

Example search request:

Product Response Structure

Frontend-friendly product payload:

Important frontend fields:

• stock → disable Add to Cart
• isInWishlist → toggle instantly
• isInCart → reflect cart state without extra calls

Pagination Contract

We support two pagination models.

Cursor-based (feeds / recommendations)

Offset-based (search results)

Mutation Contract

Mutations return the updated entity instead of success flags.

This avoids extra refetches.

Error Modeling

Consistent error format:

Extendability

The API should support future features:

• Promotions & coupons
• Subscriptions
• Multi-seller marketplace
• International shipping rules

O — Others(Performance, Accessibility, Security)

1. Performance Optimisation

Performance directly impacts SEO, conversion rate, and revenue, so this is a major focus for e-commerce.

Rendering & Bundle Optimisation

• Route-based code splitting
  Load heavy routes (checkout, account, analytics) only when needed.
• Component-level lazy loading
  Lazy load reviews, recommendations, and similar products below the fold.
• Tree shaking & vendor splitting
  Separate framework libraries from app code for better caching.
• Reduce hydration cost
  Use SSR selectively and hydrate only interactive parts of the page.

Image & Media Optimisation

Product images are the heaviest assets in e-commerce.

• Responsive images using srcset
• Lazy loading for offscreen images
• Modern formats (WebP / AVIF)
• CDN image resizing and compression
• Blur placeholders / skeleton loaders

Pagination & List Rendering Optimisation

Pagination strategy plays a major role in performance.

Cursor Pagination → Feeds & Recommendations

Used for:

• Homepage feed
• Related products
• “Customers also bought”

Performance benefits:

• Enables efficient infinite scroll
• Prevents duplicate or missing items
• Allows prefetching next cursor in background
• Avoids re-fetching entire datasets

Offset Pagination → Search Results

Used for:

• Search results pages
• Category browsing

Performance benefits:

• Supports page-based navigation (1, 2, 3…)
• Enables caching per page
• Works well with sorting and filtering
• Prevents loading large datasets at once

Virtualized Rendering

• Render only visible products in long lists
• Reduces DOM size and memory usage
• Keeps scrolling smooth even with thousands of items

2. Network & Data Fetching Optimisation

• Prefetch next page when user nears page end
• Debounce search & filter queries
• Background refetch to keep pricing and inventory fresh
• Request deduplication via React Query / RTK Query

3. Multi-layer Caching Strategy

• CDN edge caching for SSG and images
• HTTP caching headers for APIs
• Browser cache for static assets
• Memory cache for server state (React Query)
• Redux cache for cart & auth

🔐 Security

E-commerce platforms handle sensitive user and payment data.

XSS Protection

• Sanitize user-generated content (reviews, addresses)
• Avoid dangerouslySetInnerHTML
• Implement strong Content Security Policy (CSP)

CSRF Protection

• Same-site cookies
• CSRF tokens for checkout and payments
• Secure cookie flags (HttpOnly, Secure)

Secure Authentication Handling

• Store tokens in HTTP-only cookies or memory
• Session expiration and refresh flows

Data Integrity

• Never trust client-side pricing or totals
• Server validates cart, coupons, and final order

♿ Accessibility (a11y)

Accessible shopping improves usability and compliance.

Semantic Structure

• Semantic HTML for navigation, products, and forms
• <article> for product cards, <form> for checkout

Keyboard Navigation

• Full keyboard support for filters, cart, and checkout
• Proper focus management in modals and drawers

Screen Reader Support

• ARIA roles for product grids and live cart updates
• Announce dynamic changes via ARIA live regions

Visual Accessibility

• Adequate color contrast
• Scalable text
• Visible focus indicators