Designing an E-commerce frontend seems straightforward until you realize how many moving parts are involved — product discovery, cart management, checkout, payments, SEO, and performance at scale.
In this post, we’ll walk through how to design a scalable E-commerce frontend for a marketplace like Amazon or Flipkart — using the RCADO structure as our guide.
R — Requirements
What to Explain
In interviews, this is where you define the scope, goals, and constraints before jumping into architecture.
Clarify what the product needs to do (functional) and how well it needs to do it (non-functional).
Functional Requirements
Users should be able to:
- Browse and search for products with filters and pagination.
- View detailed product information including multiple images, price, and description.
- Add products to cart, edit quantities, or remove items.
- Use Buy Now for single-product purchase directly from the PDP.
- Proceed through a checkout flow collecting address and payment info.
- View order confirmation and history.
- Continue as a guest or signed-in user.
Non-Functional Requirements
- Pages should load under 2 seconds for optimal conversion rates.
- Fast, smooth interactions with minimal blocking.
- Responsive design across desktop, mobile, and tablets.
- SEO-optimized product and category pages.
- Localized pricing and currency.
- Accessible (ARIA-compliant).
- Secure handling of payments and user data.
- Scalable for traffic spikes (sales, festivals).
Core User Flows
Standard Checkout Flow
Browse → Add to Cart → Checkout → Payment → Confirmation
Buy Now Flow
Product Details → Buy Now → Checkout → Payment → Confirmation
Interview Tip:
Clarify the main purchase flows early. It shows awareness of real e-commerce patterns and helps scope your design discussion.
C — Components
What to Explain
Break the UI into logical components. Define their props, responsibilities, and state ownership.
Interviewers look for clean data flow — which component owns what and why.
Component | Props | Responsibility |
|---|---|---|
ProductList | products, onAddToCart, pagination | Displays grid/list of product cards with pagination. |
ProductCard | id, name, price, image, currency, onAddToCart | Represents a single product; used across PLP and recommendations. |
ProductDetails | product, onBuyNow, onAddToCart | Renders detailed info, images, and purchase actions. |
Cart | items, onQuantityChange, onRemove, onCheckout | Displays all cart items, handles updates, computes total. |
CartItem | product, quantity, onQuantityChange, onRemove | Renders one cart item and quantity controls. |
CheckoutForm | address, payment, onSubmit | Collects and validates checkout info. |
OrderSummary | items, total, currency | Displays order totals before submission. |
OrderConfirmation | order, onContinueShopping | Shows confirmation after successful purchase. |
Navbar | cartCount, onSearch, onNavigate | Global header with search, navigation, and cart access. |
SearchBar | query, onSearch | Handles keyword search input. |
PriceDisplay | amount, currency | Consistent currency formatting across UI. |
PaginationControl | page, totalPages, onPageChange | Manages pagination navigation. |
Ownership & Flow
- ProductList owns the product collection and pagination state.
- Cart owns cart-level data (items, totals) and syncs with global store.
- CheckoutForm manages local validation state before submission.
- Navbar reads global state (e.g., cart count, auth status).
- ProductDetails triggers Buy Now or Add to Cart actions upward.
Top-down data, bottom-up actions ensure predictable updates and maintainability.
Interview Tip:
Explain why certain state lives higher — e.g., “Cart is global because users can add items from anywhere, and the cart icon must always reflect its state.”
A — Architecture
What to Explain
Focus on rendering strategy, routing, and state management trade-offs.
Interviewers expect you to reason through why you pick a model, not just which one.
Components Tree
It’s optional to draw the components tree, but if you can draw and explain each, this will be really good.
Routing
Route | Primary Resource | Responsibility |
|---|---|---|
/ | Homepage | Fetches featured products. |
/products | Product list | Fetches paginated results, supports filters. |
/product/:id | Product | Fetches single product details. |
/cart | Cart | Displays current items and totals. |
/checkout | Checkout | Captures address and payment info. |
/order/:id | Order | Shows confirmation and summary. |
Rendering Approaches
Method | Pros | Cons |
|---|---|---|
Server-Side Rendering (SSR) | Fast first paint, SEO-friendly, localized content. | Higher server load, slower transitions. |
Client-Side Rendering (CSR) | Great interactivity, lower server cost. | Slow first load, poor SEO. |
Hybrid (SSR + Hydration) | Combines SEO + dynamic UX. | Slightly complex setup. |
Choice:
Use Hybrid SSR + Hydration via Next.js or Remix.
E-commerce needs SEO and personalization — SSR handles the first paint, hydration takes care of interactivity.
SPA vs MPA
Type | Description | Pros | Cons |
|---|---|---|---|
SPA | Single bundle; client handles routing. | Smooth transitions. | Larger bundle size. |
MPA | Server handles routing. | Better SEO, simpler. | Full reload per page. |
Choice:
E-commerce sites like Walmart and Flipkart use universal SPA (SSR + Hydration) for fast first load and smooth navigation.
State Management
Type | Description | Where It Lives |
|---|---|---|
Local State | Form inputs, modals, UI toggles. | Component-level. |
Global State | Shared data (cart, user session). | Client store (Redux, Zustand). |
Server State | API-driven data. | React Query or SWR. |
Persistent State | Cached or offline data. | localStorage or IndexedDB. |
Choice:
- Cart → global state (shared everywhere).
- Product data → server state (fetched per route).
- Checkout form → local state.
- Currency/localization → global config.
REST vs GraphQL
When designing API communication for a large e-commerce frontend, a key decision is whether to use REST or GraphQL. Both can support a modern web stack, but they differ in how efficiently they handle data fetching across multiple clients.
Approach | Pros | Cons |
|---|---|---|
REST | Simple, widely supported, easy caching. | Over-fetching and under-fetching are common — mobile and web often need different data shapes. |
GraphQL | Flexible, reduces network overhead, ideal for diverse clients (web, mobile, tablet). | Slightly more complex setup and caching. |
Choice:
For a modern e-commerce platform, GraphQL is the better fit.
It allows the frontend to tailor requests — for example, the mobile app may only need product name and price, while the web client may require detailed specs, reviews, and recommendations.
This flexibility minimizes payload size and improves performance across platforms, especially when scaling personalization features or supporting multiple form factors.
Interview Tip:
Tie data ownership to routes. For example: “/product/:id owns the canonical product object, and updates (e.g., adding to cart) trigger store sync.”
Pagination Strategy
Pagination in e-commerce ensures scalable browsing across thousands of products. The choice depends on data stability and user flow — product listings often change in real time, while search results remain relatively stable.
Type | How It Works | Pros | Cons |
|---|---|---|---|
Offset-based | Uses page numbers (e.g., | Simple to implement, easy for search result navigation. | Can skip or duplicate items if product data changes during pagination. |
Cursor-based | Uses a unique key (e.g., | Consistent for dynamic or frequently changing data (e.g., recommendations, trending lists). | Slightly more complex to implement and cache. |
Choice:
Use cursor-based pagination on landing pages (e.g., “New Arrivals”, “Deals of the Day”, or category feeds) where data updates frequently.
Use offset-based pagination for search results, where ordering is deterministic and users often need direct page access (e.g., jump to page 5).
This balance ensures consistent performance and accuracy while maintaining intuitive navigation for users.
D — Data Model
What to Explain
Describe key entities, their relationships, and ownership.
Focus on clarity — interviewers care more about data flow than exact schema syntax.
type Product = {
id: string
name: string
description: string
price: number
currency: string
images: string[]
}
type CartItem = {
product: Product
quantity: number
subtotal: number
}
type Cart = {
items: CartItem[]
total: number
currency: string
}
type Address = {
name: string
street: string
city: string
country: string
postalCode: string
}
type Payment = {
cardNumber: string
expiry: string
cvv: string
}
type Order = {
id: string
items: CartItem[]
total: number
address: Address
payment: Partial<Payment>
}
Ownership
- Cart lives in the global store.
- Product and Order fetched from server.
- Checkout data lives locally until submission.
Data Flow
- Fetch product list or product details.
- Add items to cart → global store updates.
- Checkout form submits → API
/orderreturns confirmation. - Server computes totals; client displays order summary.
Interview Tip:
Explain that price computation happens server-side — it avoids mismatches when discounts or currency rates change.
Also, mention data normalization — it helps avoid redundant fetches and keeps UI reactive.
O — Other (Performance, Accessibility, Security)
What to Explain
This is where senior-level reasoning shows. Cover optimization, accessibility, and security best practices.
Performance
- Code-split bundles by route.
- Lazy-load below-the-fold images.
- Prefetch PDP data on hover from PLP.
- Serve images via CDN in WebP/AVIF formats.
- Use caching and CDN edge rendering for hot pages.
- Prefetch checkout scripts after cart load.
Accessibility
- Semantic HTML:
<section>,<article>for product areas. - Proper ARIA roles for interactive controls.
- Keyboard-friendly navigation and focus management.
- High color contrast and readable typography.
Security
- Sanitize and escape all dynamic content.
- HTTPS and secure cookies for session.
- No unencrypted storage of payment data.
- CSRF tokens for cart and checkout actions.
- Content Security Policy (CSP) to prevent XSS.
Interview Tip:
Tie these to real-world scale — e.g., “E-commerce pages are image-heavy, so lazy-loading and CDN delivery directly improve Core Web Vitals.”
Summary
This design comfortably fills a 60-minute frontend system design interview. Every decision — from rendering strategy to state ownership — should be backed by clear reasoning. Be prepared to explain why SSR with hydration was chosen over pure CSR, how the cart’s global state improves consistency, and why modular components help scale across product and checkout pages.
Interviewers may also go deeper into topics like transaction handling, credit card encryption, and data security. Understanding concepts such as tokenization, TLS encryption, and format-preserving (Voltage) encryption can help you stand out — showing that you not only think in terms of frontend flow but also understand how user data stays secure across the full purchase lifecycle.