Design an E-commerce Product Listing

SDUI means the server returns a layout descriptor (JSON with component types and data) rather than just raw data. The app renders components dynamically based on the type field. Benefits: (1) No app update needed to change the home page layout — add a new banner, reorder sections, or run a seasonal sale layout by changing only the server response; (2) A/B testing: serve different layouts to different user segments; (3) Personalisation: the home feed can be different per user based on purchase history. The client's responsibility is rendering any valid component type correctly and gracefully degrading unknown types.

During JSON deserialization, use a polymorphic deserializer (e.g., Gson's RuntimeTypeAdapterFactory or Kotlin Serialization's @JsonClassDiscriminator). When the type field is unrecognised, map it to an Unknown sealed class variant. In the adapter's getItemViewType, the Unknown variant returns a special view type. The UnknownViewHolder inflates a View.GONE layout — it renders nothing, occupying zero height. This prevents a crash while leaving a no-op placeholder. Alternatively, use @JsonAdapter with a fallback null and filter nulls before binding.

flatMapLatest cancels the previous coroutine/flow when a new value arrives on the upstream flow. If the user changes the sort from "Price: Low to High" to "Popularity" while a page fetch is in-flight, flatMapLatest cancels the old Pager and its pending HTTP requests, then starts a fresh Pager with the new filter. Using flatMap (without Latest) would let both Pagers run concurrently — the results of the old filter could arrive after the new filter's results and overwrite them, showing the wrong products. Combined with debounce on the filter flow, this ensures only one API call fires per user interaction.

Expose the search text as a MutableStateFlow<String> in the ViewModel. In the Fragment, collect text changes from the SearchView or EditText and call viewModel.onQueryChanged(text). In the ViewModel: queryFlow.debounce(300).distinctUntilChanged().flatMapLatest { query -> searchApi.suggest(query) }. debounce(300) waits 300 ms after the last keystroke before emitting. distinctUntilChanged() skips re-running if the user typed then deleted the same letter. flatMapLatest cancels the in-flight suggestion API call if the user types again before it completes.

Scope a CartViewModel to the Activity (not individual Fragments): val cartVm: CartViewModel by activityViewModels(). It exposes a cartCount: StateFlow<Int> backed by a Room query: SELECT COUNT(*) FROM cart returning a Flow<Int>. Every Fragment and the Activity's toolbar observe this same Flow. When any Fragment adds/removes a cart item and Room updates, the Flow emits and every observer receives the new count simultaneously — no event bus, no broadcast, no manual notification. The ViewModel survives Fragment transactions and navigation, keeping state consistent throughout the session.

On "Add to Cart" tap: (1) Immediately INSERT the item into Room with syncStatus=PENDING; (2) The cart badge count updates reactively from Room — user sees it increment instantly; (3) Fire POST /cart in a background coroutine. On API success: UPDATE syncStatus=SYNCED. On API failure (4xx/network error): DELETE the item from Room — the badge decrements back, and show a Snackbar "Failed to add to cart. Retry?". For offline: keep the PENDING row in Room and enqueue a WorkManager job. The key insight is that the source of truth for the count is always Room — the API just keeps the server in sync.

Use StaggeredGridLayoutManager(2, StaggeredGridLayoutManager.VERTICAL) for product grids where image heights vary (portrait vs landscape products). For uniform-height cards, use GridLayoutManager(context, 2). With Paging 3, the PagingDataAdapter works with both. For the header row (filter bar, sort chips), set the header ViewHolder to span both columns: in GridLayoutManager, override setSpanSizeLookup returning 2 for the header position. In StaggeredGrid, call params.isFullSpan = true in onBindViewHolder for header items.

Three layers: (1) onResume re-fetch: the PDP ViewModel calls fetchLivePrice(productId) every time the screen is resumed. This covers users who left the PDP and came back. (2) Short max-age: set Cache-Control: max-age=60 on the price endpoint — OkHttp serves cache for 60 s, then revalidates. (3) SSE push (advanced): for true flash sales, the server sends a price update via Server-Sent Events on the /product/{id}/live endpoint — the client updates the price badge in real-time. On "Add to Cart", always hit the price API one last time to confirm the current price and show a "Price changed" dialog if it differs from what the user saw.

Use a ViewPager2 for the image gallery (swipe between images). For pinch-to-zoom within each image, use PhotoView library (wraps ImageView with matrix-based pan/zoom) or implement a custom ScaleGestureDetector. Double-tap toggles between fit-to-screen and 2x zoom. The zoomed ImageView intercepts touch events, so configure viewPager2.isUserInputEnabled = false when the image is zoomed (zoom > 1.0) to prevent accidental page swipes while panning. When zoom resets to 1.0, re-enable swipe.

Use RecyclerView.addOnScrollListener to detect when items become visible. Alternatively, attach a VisibilityTracker that uses each ViewHolder's itemView.getGlobalVisibleRect() to compute visibility percentage on scroll settle. An item is "impressed" when ≥50% visible for ≥1 second. Collect impression events in a batch list in the ViewModel. Flush the batch to analytics API every 30 s or on Fragment.onStop. Don't fire one API call per impression — batch them: POST /impressions [{productId, position, rankScore, timestamp}]. This data feeds the search ranking and recommendation models server-side.

When the user wishlists an out-of-stock product, send POST /wishlist {productId, notifyOnRestock: true}. The server subscribes the user's FCM token to the product's restock topic. When stock is replenished, the server sends an FCM data message with {type: "RESTOCK", productId: "XYZ", productName: "Nike Air Max"}. The FirebaseMessagingService.onMessageReceived() handler builds and shows a notification with a PendingIntent deep-linking to the PDP. On the client Room side, update the product's inStock flag so the Wishlist screen shows updated availability without an extra API call.

The product API returns a variants map: {size: [S, M, L, XL], colour: [Red, Blue]} with a variantMatrix mapping combinations to availability and price. Render each dimension as a horizontally scrollable chip group. Selected chips are highlighted. On selection, look up the combination in the variant matrix to: (1) update the displayed price; (2) grey out unavailable combinations; (3) update the product image if colour changed (each colour has a separate image array); (4) update the skuId passed to the cart API. If a combination is out of stock, show "Notify Me" instead of "Add to Cart".

Configure OkHttp with a disk cache: OkHttpClient.Builder().cache(Cache(cacheDir, 20L * 1024 * 1024)).build(). The server sets Cache-Control: max-age=300 on product listing responses. OkHttp stores the response and serves it from disk for 5 minutes without hitting the network. When the user navigates back to the same category, the listing appears instantly. After max-age expires, OkHttp revalidates using the ETag header — if unchanged, the server returns 304 and OkHttp serves from cache again. This is the HTTP-layer equivalent of offline-first for read-only data where Room isn't needed.

Model button state as a sealed class: CartButtonState { Idle | Loading | InCart | Error }. On tap: set state to Loading → disable button, show spinner. On success: set to InCart → show "Go to Cart" with green background. On error: set to Error → show "Retry" with red background, re-enable button. The ViewModel exposes this as a StateFlow<CartButtonState>. Because we write to Room optimistically before the API call, the cart badge updates immediately regardless of the button state. The button state only reflects the API sync status — it's a cosmetic indicator, not the source of truth for cart contents.

Use ConcatAdapter merging three adapters: (1) SortFilterAdapter — a single-item adapter showing the sort bar and active filter chips; (2) PagingDataAdapter — the infinite product grid; (3) LoadStateAdapter — the loading footer. Set GridLayoutManager.SpanSizeLookup: the header spans all 2 columns (spanSize=2), product cards span 1 each. When filter chips are tapped, update FilterState in the ViewModel → flatMapLatest creates a new PagingDataAdapter source → the RecyclerView resets to the top smoothly. The header adapter is not recreated — only the product adapter refreshes.

Use Paging 3's TestPager: val pager = TestPager(PagingConfig(pageSize=20), ProductPagingSource(fakeApi, filters)). Call pager.refresh() and assert the returned LoadResult.Page contains the expected products. Call pager.append() to test pagination. For the filter integration test: create a FakeProductApi that checks the query parameters match the FilterState. Test error paths by having the fake API throw an exception and assert LoadResult.Error. For the ViewModel's flatMapLatest: use Turbine to collect Flow emissions and assert the correct PagingData is emitted after each filter change.

A comparison tray is a global floating widget visible across screens. Model the comparison list as an Activity-scoped CompareViewModel with a StateFlow<List<Product>> (max 3 items). Each PDP has a "Compare" checkbox that writes to/from this ViewModel. A persistent bottom tray Fragment (added to the Activity layout, not per-Fragment) observes the CompareViewModel and shows thumbnails of selected products. On "Compare Now": navigate to a dedicated CompareFragment that renders a scrollable table mapping spec names → values across the selected products. Specs are fetched in parallel with async { api.getProduct(id) }.await() for each product.

The search API has rate limits because Elasticsearch queries are expensive. Defense layers: (1) Debounce (already in place) — 300 ms delay prevents keystroke-per-request; (2) OkHttp Authenticator / Interceptor: on 429, read the Retry-After header and delay the retry accordingly; (3) OkHttp cache: for the same query + filters, serve from cache for 60 s before re-hitting the server; (4) Exponential backoff in Retrofit: on 429, use Kotlin's delay() before retry. For the PagingSource: return LoadResult.Error on 429 — Paging shows the retry button via LoadStateAdapter, letting the user manually retry rather than hammering the server.

Send the user's auth token with GET /home. The server's personalisation engine uses purchase history, browsing history, and segment data to build the SDUI response with personalised product IDs and section ordering. The client renders it generically — it doesn't know it's personalised. For cache strategy: personalised home pages must have a user-specific cache key (include user ID in the URL or cache key), so user A's cached home page isn't served to user B on a shared device. Set a shorter max-age (e.g., 5 minutes) for personalised responses vs 30 minutes for non-personalised category pages.

Key accessibility requirements for product cards: (1) Content description: imageView.contentDescription = "Nike Air Max, ₹5,999, 4.3 stars, 30% off" — merge all card info into one meaningful description so TalkBack reads it in one swipe rather than announcing each element separately; (2) Import for accessibility: set card.importantForAccessibility = IMPORTANT_FOR_ACCESSIBILITY_YES; (3) Minimum touch target: 48dp × 48dp for Add to Cart and Wishlist buttons — use TouchDelegate or padding to expand small icons; (4) Price changes: use ViewCompat.setAccessibilityLiveRegion(priceView, ACCESSIBILITY_LIVE_REGION_POLITE) so TalkBack announces price updates without interrupting ongoing speech.

Three strategies: (1) Redis DECR — before writing to DB, run DECR inventory:{productId}. If result < 0, run INCR to restore and return 409. Sub-millisecond and handles thundering herd; best for flash sales. (2) Optimistic locking — DB row has a version column. UPDATE inventory SET stock=stock-1, version=version+1 WHERE product_id=? AND version=? AND stock>0. If 0 rows updated → 409. Best for low-contention scenarios. (3) Pessimistic locking (SELECT FOR UPDATE) — serialises all writers; safe but creates a bottleneck under flash-sale load. In practice: Redis DECR as the fast gate, async DB write through a queue, SSE to propagate Sold Out to all open clients.

Optimistic UI + rollback: (1) On tap, immediately write a PENDING item to Room and render it in the RecyclerView — zero perceived latency. (2) Fire POST /cart to the server. (3) On HTTP 409 (inventory exhausted), delete the PENDING row from Room and call adapter.notifyItemRemoved() to animate it out. Show a Snackbar: "Sorry, this item just sold out." (4) On HTTP 503 (queue full during flash sale), keep the item in Room as QUEUED and poll for confirmation. (5) On IOException (no network), keep as PENDING with a retry indicator — WorkManager retries with exponential backoff when connectivity returns.

Three-tier approach: (1) SSE (primary) — each app opens a persistent SSE connection. When stock hits 0, the inventory service publishes to a Pub/Sub topic; fan-out workers push data: {"productId":"X","stock":0} to all open SSE streams. Latency <200ms, no polling. (2) FCM (background) — for apps backgrounded or on flaky networks, send a high-priority FCM data message. Latency 1–30s but guaranteed delivery via FCM's retry mechanism. (3) onResume sync (fallback) — every time the app foregrounds, hit GET /products/{id} and refresh stock UI from the response. Catches anything missed by SSE or FCM. The client marks a product view as stale if its SSE connection dropped; on reconnect it re-fetches fresh stock before showing the PDP.

Optimistic locking: best when contention is rare (most SKUs most of the time). No locks held, reads are free, only the occasional retry on conflict. Fails under high concurrency because retry storms amplify DB load. Redis DECR: best for high-contention scenarios (flash sales, limited drops). Atomic, sub-millisecond, handles thousands of RPS without DB pressure. Downside: Redis is in-memory — needs AOF persistence or a DB reconciliation job to avoid ghost stock on restart. Pessimistic locking (SELECT FOR UPDATE): simplest correctness guarantee but serialises all writers on the same row. Fine for back-office tools or very low throughput. Avoid in user-facing flows with >50 concurrent buyers on the same SKU — lock wait timeouts cascade into timeouts and retries. In production: use Redis DECR as a fast pre-check, then optimistic locking in DB for the authoritative write.

Server is source of truth. (1) Idempotent writes: every POST /cart uses ON CONFLICT (user_id, product_id) DO UPDATE SET quantity = cart.quantity + EXCLUDED.quantity so duplicate adds from two devices merge quantities rather than overwrite. (2) SSE cart-update events: after any successful cart write, the server pushes data: {"type":"cart_updated"} to all other active SSE connections for that user. The receiving device calls GET /cart and calls cartDao.replaceAll(serverItems) — a single transaction that DELETEs local cart and batch-INSERTs the server state, keeping Room exactly in sync. (3) onResume sync: as a fallback, every time either device foregrounds, it fetches GET /cart and replaces local state. This catches any SSE events missed while backgrounded. The result: both devices always converge to the same cart within <500ms of any change on either side.