UIREADY.dev
30% offEnding soon
FSD-021Frontend system design Premium

Design an Enterprise Data Table

Design an enterprise data table with remote queries, stable identity, virtualization, editing, column state, accessibility, and conflict handling.

Intermediate 56 min read

An enterprise data table is a coordinated query, rendering, interaction, and mutation system. The server owns the canonical row set. The browser owns a bounded view of it. Stable row and column IDs keep focus, selection, saved layout, and edits attached to meaning while positions change.

A plain HTML table is often the right starting point. The architecture changes when the product needs millions of remote records, user-specific columns, pinned regions, bulk selection, inline editing, exports, and reliable keyboard navigation.

The central mistake is to treat the visible grid as the dataset. It is only a projection. Filtering or sorting can replace the query. Virtualization can replace the mounted rows. Column customization can replace visual positions. None of those replacements should change the identity of a row, column, cell, selection, or edit.

Clarify the table product

Ask whether data is local or remote, how many rows and columns exist, which operations must be server-authoritative, and whether cells are editable. Clarify bulk actions, exports, live updates, saved views, permissions, density, mobile use, localization, and assistive technology support.

For this interview, assume an authenticated operations application. A table can represent hundreds of thousands of accounts and dozens of columns. The server performs filtering, multi-column sorting, pagination, authorization, totals, and export. The browser virtualizes rows and optional columns, stores compatible user layout preferences, supports row selection and versioned inline edits, and remains usable with a keyboard and screen reader.

Spreadsheet formulas, arbitrary rectangular ranges, collaborative cursors, and pivot aggregation are separate systems.

The public interview prompt

Design a reusable enterprise data-table platform. Explain:

  • the query model for remote filtering, sorting, pagination, totals, and cancellation;
  • stable row and column identity across replacement, reordering, and virtualization;
  • normalized caching, request generations, cursor merging, and live updates;
  • row and column windowing, pinned regions, measurement, and scroll anchoring;
  • column visibility, order, width, persistence, migration, and permissions;
  • keyboard focus, selection, inline editing, validation, optimistic display, and conflicts;
  • loading, empty, partial, stale, offline, forbidden, and export states;
  • accessibility, internationalization, security, privacy, performance, and observability;
  • testing, rollout, trade-offs, and simpler alternatives.

What the premium solution covers

The full solution defines a canonical query contract, generation guard, normalized row cache, stable cell coordinates, cursor merge rules, responsive rendering window, column-state migration, keyboard modes, selection semantics, and versioned edit protocol.

Original media follows a query replacement into an edit conflict, separates logical identity from visual position, explains two-axis rendering, and records the edit ledger. Two deterministic labs let you resolve remote queries out of order and exercise accepted, ambiguous, and conflicting cell edits.

Premium solution

Continue with the complete system design

Unlock the architecture, state machine, API contracts, original diagrams, positioning model, accessibility decisions, performance budgets, testing plan, rollout strategy, scoring rubric, and interview walkthrough.

  • Detailed, beginner-friendly explanation
  • Production failure modes and trade-offs
  • Mobile-friendly architecture diagrams
  • Senior and staff-level interview signals
Unlock Premium

Frequently asked questions

Should an enterprise data table sort and filter in the browser?
Only when the complete relevant dataset is already local and small enough. For remote or authorization-sensitive data, the server should own canonical filtering, sorting, pagination, and totals.
How should a virtualized data table expose row positions?
Expose counts and indices for the complete logical grid. Use stable focus management and ensure the active cell is mounted before moving focus to it.
What identifies a cell in a data table?
Use a stable row ID plus a stable column ID. Visual row index and column position change after sorting, filtering, hiding, pinning, and reordering.
How should inline edits handle concurrent changes?
Submit the row version the edit began from. On conflict, preserve the local draft, show the current server value, and let the user reload, compare, or intentionally overwrite when policy permits.
Where should column preferences be stored?
Store user preferences by table and schema version, keyed by stable column IDs. Migrate saved state against current definitions and keep required or unauthorized columns under server policy.
Is an enterprise data table the same as a spreadsheet?
No. A data table presents and edits records whose schema and authority usually live on a server. A spreadsheet adds formula graphs, arbitrary ranges, fill operations, and broader document semantics.