When an interviewer says, "Design Spotify," the prompt may include play, pause, shuffle, volume, playlists, search, recommendations, and offline mode. A forty-five-minute round cannot give every feature equal architectural depth. The candidate has to decide which parts of the product belong in the design, which behaviors can be covered briefly, and which requirements contain decisions substantial enough to deserve the remaining time.

That triage produces three distinct treatments. A prompt item can be excluded from the agreed design scope; it remains a real product requirement, not a "fake" one. Required behavior can remain in the design but receive only a boundary, interface, and explicit assumptions when it introduces no consequential decision. An in-scope requirement merits design depth when it changes a pending architectural choice, threatens an agreed service objective, or introduces material risk under the stated workload and assumptions.

Requirements gathering establishes the core use cases, system boundary, constraints, service objectives, and product priorities. In a time-boxed interview, it also performs architectural triage. Spending the opening minutes on every product feature leaves too little time for the decisions that shape the system, while moving past a small-sounding feature too quickly can miss a distributed-systems problem hidden inside it. Feature placement, workload estimates, and actor modeling are useful here only when they change that prioritization.

The Spotify trap

Play, pause, shuffle, and volume are easy features to name first, which makes them a tempting place to start. For an already authorized and sufficiently buffered session, however, the immediate control actions are ordinarily local. Changing volume adjusts the device's output level. A play or pause command can be handled inside the local playback pipeline. Reordering a queue the client already possesses does not inherently require a synchronous backend decision.

That does not mean the complete product behavior around playback is server-free. Starting or resuming the end-to-end stream may depend on authorization, subscription or regional-entitlement checks, manifest retrieval, DRM licensing, advertising decisions, and access to media delivery. These are logical prerequisites, but they need not all run synchronously for every attempt. Authorization material, entitlements, manifests, or licenses may already be valid, cached, or prefetched; some can be refreshed asynchronously or handled under an explicit fallback or fail-open policy where security and product rules permit. Only work that must complete synchronously for the current start or resume attempt belongs on its startup critical path, consumes its latency budget, and necessarily blocks that attempt when unavailable.

Telemetry, history, recommendation signals, and similar reporting can usually be decoupled from that path. Reporting should block playback only when the product requires a durable must-record-before-play guarantee. Otherwise it should be emitted asynchronously with buffering and retry behavior appropriate to its durability requirements, and playback should not fail solely because reporting is unavailable. Shuffle may still incorporate server-generated recommendations or operate over a collection too large to load onto the device. Pause may update listening progress so playback can resume elsewhere.

The architectural boundary is narrower than the feature list suggests: immediate media controls do not automatically justify a backend service of their own. "Local" here means only that the immediate action requires no synchronous backend decision. Client playback architecture can still deserve depth when buffering, device constraints, offline behavior, or cross-device state is in scope.

A box labeled Playback Service is useful only if an important request or decision flows through it. Otherwise, the time would be better spent deciding how search is indexed or how audio reaches geographically distributed users. Consumer-product prompts mix local and backend behavior, and either can contain consequential architecture. The prompt may leave those boundaries unclear, so identifying and confirming them is part of the interview.

A better way to filter the feature list

A useful first pass is to ask whether a feature requires server-owned data or computation, communication across users or devices, durability beyond the local session, or authorization and coordination that cannot safely be left to the client.

An authoritative catalog of millions of tracks will ordinarily require server-owned state and synchronization, but that does not determine where every query is indexed or executed. A synchronized or cached local index may be viable when device storage, freshness, update cadence, ranking, access-control, and offline requirements allow it. Backend search is the appropriate assumption when the corpus cannot reasonably reside on clients, results require fresh centrally computed ranking or access control, or updates must be reflected without synchronizing a full index.

Cross-device playback continuity requires coordination or state exchange. Keeping the resume position available after a device disconnects or fails requires shared, durable state, while a live handoff may use ephemeral coordination or direct transfer. Adjusting the volume on one device usually requires neither.

This first pass tells you where a feature may belong, but not how much interview time it deserves. Plenty of ordinary functionality requires a server. A display name must be stored durably. A preference may need an authenticated API. A client may fetch a configuration document over the network. None of those facts automatically creates an important architectural trade-off.

Assess three dimensions separately:

• System placement: client-local, backend-owned, or spanning both. Placement identifies the relevant boundaries and interfaces; it does not by itself determine depth.
• Product centrality: core to the agreed flow, supporting that flow, or outside the agreed scope. Out-of-scope behavior is named and excluded. Core behavior remains visible end to end, while supporting behavior may be summarized when its assumptions are explicit.
• Architectural consequence: routine under stated assumptions, consequential because it changes a pending architectural choice, threatens an agreed service objective, or introduces material risk under the stated workload and assumptions, or unresolved because a missing requirement could change that judgment. Consequential items warrant investigation. Unresolved items require a question or explicit assumption before depth is assigned.

The dimensions combine rather than forming separate buckets. Exclude out-of-scope behavior regardless of its technical richness. Investigate in-scope, consequential requirements whether they run on the client, the backend, or both. Represent straightforward requirements through their boundary, interface, and assumptions; if one is core, trace it end to end without manufacturing complexity. Ask about unresolved requirements or state an assumption before assigning depth.

Start with a mixed list of immediate controls, end-to-end playback, search, single-owner playlists, collaborative editing, and offline mode. Suppose the interviewer makes listener playback and search core and accepts that collaboration and offline behavior are outside scope. Immediate controls are client-local, core, and architecturally straightforward for an authorized, buffered session, so show their client boundary and playback interface, state that assumption, and move on. End-to-end playback spans client and backend and forces latency, authorization, availability, and delivery decisions, so investigate it deeply. Search is core, but its placement remains unresolved or may span client and backend until corpus size, freshness, ranking, access-control, synchronization, and indexing assumptions are set. Resolve those assumptions, then go deep where they change index placement or execution. Under assumptions of bounded playlist size, simple ordering, no concurrent multi-device or multi-session editing, and conventional durable storage, a single-owner playlist is supporting and routine, so represent its authenticated storage interface briefly. Without those assumptions, stale writes, ordering, concurrency, and consistency remain unresolved. Exclude collaboration and offline mode despite their technical richness. The proposed interview scope is end-to-end listener playback and search, with most design time on the startup critical path and global audio delivery, enough detail on search to justify its index placement, brief coverage of immediate controls and playlist storage, and no design time on collaboration or offline mode.

Small features can hide consequential systems

Product surface area is a poor proxy for architectural consequence. A prominent feature can require little design depth, while a single product verb can conceal state, coordination, or failure decisions that shape the system.

"Two people can edit a playlist" sounds simple until both users modify the same ordered list at the same time. The system now has to decide what happens when they add tracks at the same position, when one user reorders a track while another deletes it, whether the client updates optimistically, how stale writes are detected, and what ordering guarantees collaborators observe. How much architecture this requires depends on contention and the user-visible guarantees. With low contention and simple semantics, the server might serialize writes under an explicit ordering policy. Optimistic versioning can instead detect stale writes or conditionally accept them, but it still needs a defined reject, retry, merge, last-writer-wins, or other conflict-resolution policy and a user-visible ordering rule. Stronger concurrent ordering or merge guarantees warrant deeper coordination.

"Offline mode" can name at least two different systems. For mutable-data synchronization, a disconnected client accumulates durable local changes while the server continues changing underneath it. When the connection returns, the system needs a reconciliation model: which operations merge cleanly, which conflict, how stale state is detected, whether the client retains an operation log or only a snapshot, and what the user sees when automatic reconciliation is impossible. Offline media availability raises a different set of concerns: downloading media, encrypted local storage, entitlement or license expiry, storage eviction, and playback while disconnected. Clarifying which meaning is in scope matters because the state, security, and failure paths differ.

Play history presents yet another architecture. "Show me what I listened to" may imply a write for every play event from every listener. At sufficiently large event volume, that becomes an append-heavy path with durability, retention, privacy, and aggregation concerns. A single play may produce a user-visible history entry, a recommendation signal, a royalty or billing event, a progress update, an advertising event, and product telemetry. Those records may have different schemas, guarantees, retention periods, and access controls. One product verb can map to several backend writes.

Estimate when the number changes the decision

Scale estimation is a triage tool when it determines whether a requirement changes the architecture or deserves depth. Estimate when the result could change a pending choice or test whether an assumed design can meet its objectives.

If the candidate is deciding whether a tested metadata deployment can support the workload, rough storage volume and read/write rates matter. If the design centers on play-history ingestion, event rate and retention matter. If the question is global audio delivery, bandwidth, cacheability, and geographic distribution inform the delivery design.

The estimates also need to remain separated by workload. Audio delivery is primarily a bandwidth and edge-distribution problem. Metadata search is an indexing and origin-read problem. Playlist collaboration is a shared-state and coordination problem. Play history is an ingestion and retention problem. One blended requests-per-second number does not describe all of them because each workload may bind a different resource.

Consider an explicitly illustrative bandwidth estimate. Assume one million concurrent listeners, an average encoded bitrate of 160 kilobits per second, and an origin deployment tested to sustain 20 gigabits per second while meeting its latency and resource thresholds. The aggregate listener egress for the audio payload would be about 160 gigabits per second before protocol overhead or headroom.

If every media byte were delivered directly from that origin with negligible cache or CDN offload, its tested limit would be crossed at roughly 125,000 concurrent listeners. That threshold is a direct-origin capacity boundary, not an estimate of origin traffic behind a cache or CDN. With cache or CDN delivery, origin traffic depends on misses, fills, object popularity, and cache policy even though aggregate listener egress remains about 160 gigabits per second. Geography, cacheability, latency objectives, and the resulting origin load determine whether distributed delivery deserves architectural depth; edge delivery is not merely an overflow patch applied after origin exhaustion.

At 10,000 concurrent listeners, direct audio payload would be about 1.6 gigabits per second, so bandwidth alone would not rule out that tested origin deployment, although latency and availability requirements might still favor distributed delivery. These are interview assumptions rather than claims about Spotify's traffic or infrastructure.

It is also reasonable to defer an estimate when the exact figure will not affect the immediate choice, provided the candidate explains the dependency:

For audio delivery, I'll estimate concurrent listeners and bitrate because they determine aggregate egress. I will not choose the metadata partitioning strategy yet because that depends on the dominant access patterns and estimated read and write volume. If that decision becomes central, I'll derive those numbers then.

The interviewer can challenge the assumptions, request another estimate, or redirect the discussion. Leaving the scale dimension implicit provides no basis for evaluating the pending capacity decision.

"Users" are not one workload

Separating actors is another form of triage. It shows which workloads affect the agreed architecture and which can remain outside the scope instead of being blended into one user count.

Listeners may generate heavy streaming traffic, search and browse reads, playback events, and relatively infrequent library or playlist writes. Power users and curators may maintain larger libraries, edit more playlists, and generate more synchronization activity. If collaboration is in scope, collaborators introduce concurrent writes and conflict-resolution requirements that solo playlist owners do not.

Artists and publishers belong to a different workflow. They may upload catalog content, provide metadata and rights information, trigger processing pipelines, and schedule releases. A release can create fan-out through processing, indexing, notification, cache-warming, or distribution work. Concentrated listener demand after release is instead a flash crowd on the read and delivery path. The first case requires control over downstream work and retries; the second requires sufficient serving capacity, admission behavior, and distribution.

These actors have different workload and consistency profiles. Even an anonymous listener who creates almost no user-authored state may still generate playback, advertising, recommendation, fraud, and telemetry events. An artist publishing content can trigger workflows and demand patterns that do not apply to a listener.

If the agreed scope is listener playback and delivery, publisher ingestion can be named and excluded. If release processing is central, its fan-out and retry behavior may deserve depth while playlist collaboration does not. Actor modeling helps make that boundary defensible rather than expanding the design to cover every persona.

Commit to an explicit scope

If the interviewer declines to set priorities or asks the candidate to make assumptions, state a scope, invite correction once, and continue. The proposal should name the core flow and system boundary, included and excluded behavior, simplifying assumptions and service objectives, and the decisions assigned depth.

Once that proposal is explicit, the interviewer can redirect it before the design hardens. Then continue with the decisions assigned depth rather than reopening the full feature list.