30% offEnding soon
FSD-023Frontend system design Premium

Design a Pivot-Table Builder

Design a pivot-table builder with field zones, validated aggregation, hierarchical results, server execution, virtualization, accessibility, and saved views.

Advanced 55 min read

A pivot-table builder is a query compiler with a hierarchical grid interface. Field chips describe grouping and aggregate intent. The server or local engine executes that intent. Typed grouping paths keep detail rows, null members, subtotals, and grand totals unambiguous.

Dragging “Region” into Rows looks like a presentation change. It is actually a new query. Adding “Customer” can multiply the result by tens of thousands. Moving a non-additive measure can change whether a subtotal is mathematically valid. Expanding one row can request another hierarchy page.

The design needs a field catalog, canonical pivot specification, validation and cost estimation, query ownership, normalized result tree, bounded renderer, and saved-view migration. The visible matrix is a projection of those systems.

Clarify the analytical product

Ask where source data lives, whether it is already aggregated, dataset size, freshness, permissions, supported dimensions and measures, expected cardinality, subtotal rules, drill-through, exports, saved views, and accessibility requirements.

For this interview, assume an authenticated analytics product over a remote sales dataset. Users place dimensions in row and column zones, measures in Values, and predicates in Filters. The product supports subtotals, grand totals, expand and collapse, formatting, saved views, and export. The server owns authorization and aggregation. The browser owns layout intent, validation feedback, request generations, the result tree, expansion state, focus, and rendering.

Spreadsheet formulas, arbitrary SQL, chart authoring, and cube administration are separate systems.

The public interview prompt

Design a reusable pivot-table builder. Explain:

  • semantic field metadata, field zones, drag behavior, validation, and cost estimation;
  • the canonical query specification, request generations, caching, cancellation, and saved views;
  • grouping sets, rollups, measures, nulls, subtotals, grand totals, and formatting;
  • hierarchical result identity, expansion, pagination, normalization, and virtualization;
  • server versus browser execution, workers, columnar data, partial and stale results;
  • keyboard interaction, focus, selection, treegrid semantics, and narrow-screen alternatives;
  • security, privacy thresholds, internationalization, performance, telemetry, and testing;
  • export, drill-through, rollout, rejected approaches, and interviewer follow-ups.

What the premium solution covers

The full solution defines a semantic field catalog, canonical pivot specification, compatibility validator, cardinality budget, generation guard, typed grouping path, normalized result tree, expansion contract, rendering model, and saved-view migration.

Original media follows a field layout into an owned result hierarchy, shows the field-zone grammar, explains subtotal math, and separates browser orchestration from analytical execution. Two deterministic labs test layout risk and stale hierarchy responses.

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 a browser pivot table aggregate all source rows locally?
Only for bounded datasets already resident in the browser. Large, permission-sensitive, or frequently changing datasets should be aggregated by an authorized server query.
What identifies a pivot-table result row?
Use a typed grouping path made from stable field IDs and member values. Keep null members, subtotal members, and grand totals as distinct node kinds.
How can a pivot builder avoid enormous results?
Estimate cardinality from selected dimensions and measures before execution, enforce server limits, and offer filters, sampling, top-N, or a confirmation flow for expensive layouts.
Are all measures safe to subtotal?
No. Sums and counts are additive, distinct counts are not freely additive, and averages require numerator and denominator state. The semantic field catalog must declare valid aggregations.
How should a pivot table expose hierarchical rows accessibly?
Use a tested treegrid interaction model when rows expand hierarchically. Report logical counts, levels, expansion, focus, and selection independently of virtualization.
How should saved pivot views survive schema changes?
Persist stable field IDs with dataset and semantic-model versions. Migrate compatible fields, report removed or forbidden fields, and never silently reinterpret a measure.