A production BI dashboard builder is a revisioned document editor connected to a permission-aware query coordinator. The browser owns layout and interaction; trusted services own semantic validation, authorization, query execution, shared caching, exports, and publication. Results may appear only when their dashboard revision, filters, viewer scope, and policy revision match the surface that requested them.
The first prototype often looks like a grid of charts. Drag a card, choose a metric, call an endpoint, and save JSON. That model breaks as soon as two editors work at once, a global filter refreshes twelve widgets, a late response reaches a newer draft, or one viewer is not allowed to see a dimension that another viewer can export.
A useful design separates four systems that happen to share one screen: a layout editor, a semantic query client, a coordinated result viewer, and a versioned publishing workflow. Each has its own lifecycle. The central design job is to connect them without letting one lifecycle silently overwrite another.
Clarify the product before choosing libraries
Assume a collaborative analytics product. Editors assemble dashboards from charts, tables, scorecards, text, and filter controls. They drag and resize widgets, configure semantic metrics and dimensions, preview data, save drafts, publish releases, and roll back. Viewers open published dashboards, change permitted filters, inspect details, and request exports. Embedded viewers may have a narrower permission scope.
Desktop is the primary editing surface. Tablet and mobile are first-class reading surfaces, with simple filter changes and accessible drill-downs. The browser never receives warehouse credentials or unrestricted SQL. A trusted service resolves approved semantic queries into source-specific work.
Before drawing components, ask whether the product needs live collaborative editing, pixel-perfect freeform placement, scheduled delivery, offline draft editing, cross-source joins, public embedding, or regulated exports. Each answer changes the boundary. The design below supports collaborative drafts and protected embeds, while deliberately using a constrained responsive grid instead of an arbitrary canvas.
The public interview prompt
Design a browser-based BI dashboard builder for large, permissioned datasets. Explain:
- widget contracts, chart adapters, semantic metrics, dimensions, filters, and parameters;
- drag, resize, keyboard editing, responsive placement, undo, and draft autosave;
- query planning, deduplication, caching, concurrency, cancellation, and partial failure;
- consistent multi-widget refreshes, late results, filter changes, and stale revisions;
- row and field permissions, embeds, exports, audit history, and cache partitioning;
- publishing, rollback, migrations, accessibility, mobile, observability, testing, and rollout.
What the premium solution covers
The complete solution begins with an immutable dashboard revision receipt and follows it through layout edits, semantic query planning, a bounded refresh wave, permission checks, draft conflicts, publication, embeds, and exports. It distinguishes independent widget refresh from consistency groups and shows why a result owner includes viewer context rather than query text alone.
Original media includes a revision receipt, a frame-verified coordinated refresh animation, responsive layout anatomy, and a permission partition. A deterministic query-budget lab lets the reader vary widget count, query overlap, cache hit rate, concurrency, response latency, transfer size, and render cost.