Design a scalable tagging system

Q: Design a scalable tagging system

This question tests a candidate's ability to design scalable data models and distributed indexing strategies for a multi-tenant tagging system. It evaluates system design competency across storage, caching, sharding, and consistency trade-offs — core skills assessed in senior software engineering interviews.

Q: How do I approach System Design interview questions?

System Design questions require understanding of core concepts and practice. PracHub provides solutions with explanations to help you master system design interviews.

Q: What difficulty level is this interview question?

This is a hard difficulty System Design question, commonly asked during Technical Screen rounds at Atlassian.

Q: What role is this question designed for?

This question is commonly asked for Software Engineer candidates at Atlassian during technical interviews.

Question

Design a scalable, multi-tenant tagging system that lets users attach multiple tags to arbitrary resources ("items") and query them efficiently. The system must support creating and managing tags, attaching and removing tags, and sustained high read and write traffic.

Your design should address the following deliverables:

Tag lifecycle — create / get-or-create tags, attach and remove tags from items, and prevent duplicate (item, tag) assignments.
Single-tag query — return all items for a given tag, with pagination and sorting (e.g., by recency).
Multi-tag query (AND / OR) — return items matching a combination of tags, supporting both intersection (AND) and union (OR).
Top-N per tag — efficiently list the top-N items for a tag (e.g., by recency or score).
Counts — return the number of items per tag.
Autocomplete / suggestions — prefix-based tag autocomplete and (optionally) related-tag suggestions.
Data model & storage — specify the data model and storage choices for tags, items, and assignments.
Indexing — an indexing strategy for fast writes and reads, including an inverted index (tag → items) and a forward index (item → tags), plus a way to handle high-cardinality / skewed tags.
Caching — what to cache, the cache-invalidation strategy, and hot-key handling.
Sharding / partitioning — how to partition the OLTP store and the index, including multi-tenancy isolation and hot-tag mitigation.
Consistency — choose and justify a consistency model (eventual vs. strong) and explain how to support read-your-writes.
De-duplication, rename, and merge — how tag de-duplication, renaming, and merging two tags are handled.
Access control — tenant isolation and per-resource ACL filtering.
Pagination — a stable, scalable pagination strategy.
Backfill & cleanup — reindex/backfill jobs and cleanup of orphan tags and drifted counters.
Capacity, monitoring, and SLAs — order-of-magnitude capacity estimates plus the key metrics, alerts, and SLOs.

Constraints & Assumptions

Treat these as the working numbers unless the interviewer changes them — state them explicitly and design against them.

Scale: ~100M items, average ~8 tags/item → on the order of ~800M (item, tag) assignments.
Skew: tag popularity is Zipfian; the top ~1% of tags hold roughly half of all assignments, and a handful of "hot" tags have tens of millions of items.
Traffic: reads dominate writes by roughly 10:1; both are sustained and high (order of tens of thousands of reads/sec, thousands of writes/sec).
Latency: read p95 in the tens-to-low-hundreds of milliseconds; writes must be durable and correct.
Multi-tenancy: strict tenant isolation; tags are scoped per tenant (Atlassian-style — tags live inside a site/instance, not in one global namespace).
Items are opaque references identified by (tenant_id, item_id) ; the tagging system stores references, not item bodies. Full-text search of item content is out of scope.
Tolerable staleness: counts and ordering may lag by seconds; the assignment itself (did the attach succeed?) must be strongly consistent.

Clarifying Questions to Ask

A strong candidate scopes the problem before designing. Reasonable questions to raise up front:

Are tags scoped per tenant, per project, or globally shared? Are tag names case-sensitive, and what is the normalization rule?
What is the read:write ratio and the absolute QPS we should design for, and what is the latency SLO per query type (single-tag, multi-tag, autocomplete)?
How fresh must query results be — is seconds of staleness acceptable for counts and ordering, and must a user see their own just-applied tag immediately (read-your-writes)?
Do queries need per-resource access-control filtering (can two users tagging the same tenant see different result sets), or is tenant-level isolation sufficient?
What sort orders must we support for single-tag and multi-tag queries (recency, a relevance/score, multiple)?
Are exact counts required, or are approximate (eventually consistent) counts acceptable for the common case?

What a Strong Answer Covers

The interviewer is evaluating breadth across the deliverables and depth on the hard parts. A strong answer demonstrates the following dimensions (these are the things to cover, not the answers):

Requirements & sizing — separates functional from non-functional needs, states explicit capacity estimates, and identifies skew and write fan-out as the core challenges.
Architecture & rationale — a clear high-level design (e.g. a source-of-truth store vs. read indexes) with a justified reason for the split and how the two stay in sync.
Data model — concrete schema for tags, items, and assignments; how the model itself enforces de-duplication, idempotency, and tenant isolation.
Query execution — algorithms for single-tag, AND, OR, top-N, counts, and autocomplete — not just "use a search engine," but how each is served cheaply and how counts avoid COUNT(*) on the hot path.
Skew & hot-key handling — a concrete strategy for high-cardinality tags across the index, cache, and write path.
Consistency & read-your-writes — an explicit, defended choice (strong where it matters, eventual where it's affordable) and a mechanism to mask staleness where a user would notice.
Lifecycle correctness — de-dup, rename, and merge handled without breaking existing references or moving stable identifiers.
Multi-tenancy & access control — structural tenant isolation and a strategy (pre- vs. post-filter) for per-resource ACLs, with awareness of the trade-offs.
Pagination — a stable, scalable cursor/keyset scheme that works across shards.
Operability — backfill/reindex with zero downtime, counter-drift reconciliation, orphan cleanup, and concrete SLOs, metrics, and alerts (including the single most important health signal).
Trade-off articulation — naming alternatives (search engine vs. custom postings, pre- vs. post-filter ACLs, strong vs. eventual) and defending the choice rather than asserting one right answer.

Follow-up Questions

A single tag has grown to 60M items and its queries are timing out. Walk through exactly how you detect this, split it, and migrate live traffic without downtime or lost writes.
A tenant complains that an item they tagged 30 seconds ago still doesn't appear when they query that tag. Diagnose the possible causes and describe how your design prevents (or bounds) this.
The per-tag usage_count has drifted from the true number of assignments after a partial outage. How did it drift, how do you detect and reconcile it, and how do you keep it from drifting again?
How would you extend the design to support tag-based access control changes (a resource's ACL changes) without serving stale "you can see this" results in multi-tag queries?

Design a scalable tagging system

Quick Overview

Design a scalable tagging system

Constraints & Assumptions

Clarifying Questions to Ask

What a Strong Answer Covers

Follow-up Questions

Submit Your Answer to Earn 20XP

Design a scalable tagging system

Quick Overview

Design a scalable tagging system

Constraints & Assumptions

Clarifying Questions to Ask

What a Strong Answer Covers

Follow-up Questions

Submit Your Answer to Earn 20XP