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

Design a Multi-Select with Thousands of Options

Design a large multi-select with remote search, durable selection, virtualization, accessible focus, responsive chips, and reliable APIs.

Intermediate 48 min read

Design a large multi-select as three independent layers: a durable set of selected IDs, a replaceable cache of loaded option records, and a small virtual window of mounted rows. Remote search may replace results and scrolling may replace DOM nodes, but neither operation may silently change the user's selection.

A basic multi-select can keep every option in one array and render every row. That model breaks when the catalog contains 100,000 employees, products, permissions, or customer accounts. The browser does not need every record at once, and it certainly does not need every row in the DOM.

The difficult part is not drawing check marks. It is preserving one coherent field while search results, cached records, mounted rows, and selected chips all have different lifetimes.

Start with three separate data layers

The smallest useful mental model has three layers:

  1. Selection: a set of stable option IDs. This is the user's durable intent.
  2. Loaded data: option records currently available in memory, usually indexed by ID. Search, pagination, and hydration fill this cache.
  3. Rendered window: the handful of option rows currently mounted for the visible scroll range and overscan.

An option can be selected without appearing in the current query. It can be loaded without being rendered. It can also be rendered without being selected. Treating those states as the same collection causes the most damaging bugs in this design.

Assume a permission picker backed by a 100,000-item catalog. A user normally chooses fewer than 20 items. Search returns 50 records per page, and the popup shows about eight rows. These are design assumptions, not universal limits. They make the important pressure visible: selection is tiny and durable, while discovery is large and temporary.

The public interview prompt

Design a reusable multi-select field for a frontend component platform. Explain:

  • stable identity, selected state, option records, and form serialization;
  • remote search, pagination, cancellation, stale responses, and retries;
  • fixed or variable row virtualization, overscan, measurement, and scroll restoration;
  • keyboard, pointer, touch, screen-reader, zoom, right-to-left, and international input behavior;
  • chips, hidden selections, removal, review, validation, and narrow layouts;
  • disabled, deleted, forbidden, stale, partial, offline, and empty states;
  • API contracts, caching, security, observability, testing, rollout, and evolution.

Assume the server can search options and hydrate records by stable ID. The first version does not include tree selection, drag-reordering selected chips, arbitrary controls inside options, or collaboration between multiple people editing the same field.

What the premium solution covers

The complete solution develops the three-layer model into a production design. It includes a typed state model, search and hydration APIs, query-generation guards, cursor pagination, virtual range rules, active-option pinning, accessible listbox semantics, responsive chip disclosure, ambiguous Select all behavior, degraded states, validation, security, observability, test matrices, rollout gates, and an interview scoring rubric.

Original desktop and mobile illustrations show the durable selection ledger, the moving virtual window, independent search and selection lifecycles, and a bounded chip layout. A deterministic lab lets you change the catalog size, viewport, overscan, and scroll position while selected IDs remain stable.

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

How do you design a multi-select with thousands of options?
Keep selected stable IDs as durable state, fetch and cache option records separately, and render only a measured window of rows. Remote search, virtualization, and chip layout may replace their own views, but they must never erase the selection set.
Should selected options disappear when the search query changes?
No. The query controls which options are discoverable in the popup, not which IDs are selected. Keep selection outside query results and hydrate missing labels by ID when necessary.
How does virtualization work in an accessible multi-select?
Mount the visible rows plus bounded overscan, keep the active option mounted, and expose each rendered option's logical position and total set size when only part of the collection is in the DOM. Test the result with real browser and screen-reader combinations.
Should a large multi-select support Select all?
Only after defining its scope. Select all visible, select all loaded, and select all matching the current remote filter are different operations. For a remote catalog, an explicit filter expression with exclusions is safer than materializing every ID in the browser.
What should the form submit for a large multi-select?
Submit stable option IDs, not labels or row indexes. The server must revalidate permission, existence, and business constraints because browser state can be stale or modified.
How should selected chips behave on mobile?
Keep the field height bounded. Show a small number of chips or a compact summary, provide a clear way to review and remove every selection, and keep remove controls large enough to operate without horizontal page scrolling.
Is remote search enough, or is virtualization still needed?
They solve different costs. Remote search limits transferred and cached records. Virtualization limits mounted rows and layout work for the current result set. A product may need either one or both.