Social Bookmarking System Design: del.icio.us Case Study (2026)

Social Bookmarking System Design: The del.icio.us Interview Question

"Design a social bookmarking service like del.icio.us." This question looks harmless, and that is exactly why interviewers love it. There is no exotic technology in it, yet it quietly tests everything: requirements clarification, capacity estimation, a many-to-many data model, and read-heavy scaling. If you can walk through this one cleanly, you can walk through most product design questions.

A quick history check, because candidates often think this is a made-up product. del.icio.us was a real social bookmarking service, launched in 2003, and it became popular enough that Yahoo acquired it in 2005. The idea was simple: instead of saving bookmarks inside your own browser, you save them to a website. Every bookmark gets tags like programming or recipes, and because bookmarks are public, anyone can browse the programming tag page and see what the whole community is saving. Think of it as a shared pin board for the internet.

Step 1: How Do You Clarify Requirements for a Bookmarking Service?

Never start drawing boxes. Start by shrinking the problem. Here is the split I would say out loud.

Functional requirements

• A user can save a bookmark: a URL plus a title, optional notes, and a list of tags.
• A user can view their own bookmarks, newest first, with pagination.
• Anyone can view another user's public bookmarks.
• Anyone can browse a tag page: all recent bookmarks tagged python, for example.
• A popular page shows URLs saved by the most people recently.

I would explicitly push search, recommendations, and social following out of scope. Saying "out of scope" is not dodging; it shows the interviewer you know a 45-minute interview cannot cover everything.

Non-functional requirements

• Read-heavy: far more people browse bookmarks than save them. Assume a 100:1 read-to-write ratio.
• Availability over consistency: if a tag page is 30 seconds stale, nobody notices. If the site is down, everybody notices.
• Low read latency: tag pages and user pages should load in under 200 ms.
• Durability: a saved bookmark must never be lost. People trusted this service with years of collected links.

Step 2: Back-of-the-Envelope Capacity Estimation

Now do the arithmetic honestly, because the numbers decide the architecture. Assume 10 million registered users and 2 million daily active users.

1. Writes: if an active user saves about 3 bookmarks per day, that is 2M x 3 = 6 million writes per day. Divide by 86,400 seconds: roughly 70 writes per second on average, maybe 200 per second at peak. That is tiny. A single decent database handles it.
2. Reads: with a 100:1 ratio, 6 million writes per day implies 600 million reads per day, which is about 7,000 reads per second on average and perhaps 20,000 at peak. This is where the design pressure lives.
3. Storage: a bookmark row is roughly 500 bytes (a 200-byte URL, a title, notes, ids, timestamps). 6M per day x 365 days is about 2.2 billion bookmarks per year, so 2.2B x 500 bytes is roughly 1.1 TB per year. Tag mappings at maybe 3 tags per bookmark add a few hundred gigabytes more.

Say the conclusion out loud: storage is trivial, writes are trivial, reads are the problem. Everything after this moment should be aimed at serving 20,000 reads per second cheaply. This is the same shape of conclusion we reached in the URL shortener case study, and interviewers reward candidates who let the numbers drive the design instead of decorating a diagram with every buzzword they know.

Step 3: What Does the API Look Like?

Keep the API boring and RESTful. Boring is a compliment in an interview.

• POST /api/v1/bookmarks with body {url, title, notes, tags[]} creates a bookmark.
• GET /api/v1/users/{username}/bookmarks?page=2 lists a user's bookmarks, newest first.
• GET /api/v1/tags/{tag}/bookmarks?page=1 lists recent bookmarks for a tag.
• GET /api/v1/popular returns the most-saved URLs of the last day or week.
• DELETE /api/v1/bookmarks/{id} removes one of your own bookmarks.

Two details earn extra credit. First, pagination on every list endpoint, because tag pages can have millions of entries. Second, idempotency: if a user saves the same URL twice, update the existing bookmark instead of creating a duplicate. That means normalizing URLs (lowercase the host, strip tracking parameters) before comparing them.

Step 4: Data Model — Users, Bookmarks, and Tags

This question exists largely to see if you can model a many-to-many relationship. One bookmark has many tags; one tag belongs to many bookmarks. The classic answer is four tables:

• users: id, username, email, created_at
• bookmarks: id, user_id, url, title, notes, created_at
• tags: id, name (each tag name stored exactly once)
• bookmark_tags: bookmark_id, tag_id (the join table that makes many-to-many work)

Think of tags like the labels a librarian sticks on magazine clippings. The clipping is stored once; the labels are cheap little pointers that let you find it from many directions.

Indexes are where average candidates stumble. You need an index on bookmarks(user_id, created_at) so a user page is one cheap range scan, and an index on bookmark_tags(tag_id, bookmark_id) so a tag page does not scan the whole join table. For the popular page, add a urls table keyed by the normalized URL with a save_count, so counting "how many people saved this link" does not require grouping billions of rows at request time.

Step 5: How Do You Scale a Read-Heavy System?

We estimated 20,000 peak reads per second against 200 writes. The playbook for that shape is caching in front, replication behind.

Caching: put a cache like Redis in front of the database and use the cache-aside pattern for the three hot read paths: user pages, tag pages, and the popular page. Even a short TTL of 60 seconds absorbs almost all repeat traffic, because a thousand people loading the programming tag page in one minute should trigger one database query, not a thousand. I cover the patterns and their trade-offs in caching strategies for system design.

Replication: behind the cache, run one primary database for writes and several read replicas for cache misses. Since we agreed availability beats consistency, replication lag of a second or two is acceptable: a fresh bookmark appearing slightly late on someone else's screen harms nobody. If this pattern is new to you, read master-slave replication explained first, because interviewers expect you to mention lag before they ask.

The Tag-Page Fanout Problem

Here is the part that separates a good answer from a memorized one. When a user saves one bookmark with five tags, that single write must eventually show up on five different tag pages plus the user's own page. That multiplication is called fanout, and you have two ways to pay for it:

1. Fanout on read: store the bookmark once, and build each tag page at request time with a join. Writes are cheap; reads do the work. With caching on top, this is usually enough here.
2. Fanout on write: when the bookmark is saved, push its id onto a precomputed list for each of its tags (for example a Redis list per tag, capped at the newest 1,000 entries). Reads become a single list lookup; writes do five small extra operations.

For a bookmarking service, I would say: start with fanout on read plus a 60-second cache, and move only the hottest few hundred tags to precomputed lists. Popular tags like programming get constant traffic and constant new entries, so a materialized list saves the database from rebuilding the same page all day. Cold tags with ten bookmarks are not worth precomputing. Choosing per-tag instead of one-size-fits-all is exactly the kind of judgment interviewers are probing for.

What Breaks at 10 Million Users?

Finish with failure modes before anyone asks. Three things crack first:

• Cache stampede on hot pages. When the programming tag page expires, thousands of concurrent requests can miss at once and hammer the database together. Fix it with request coalescing (only one request rebuilds, the rest wait) or by refreshing hot keys just before expiry.
• The cache outgrows one machine. A working set of hot tag and user pages eventually exceeds one Redis node's memory, so you shard the cache across nodes. Use consistent hashing to place keys, so adding a cache node does not invalidate almost everything at once.
• Hot rows and skew. A viral link means thousands of increments on one save_count row. Batch those counter updates, or accept approximate counts computed by a periodic job. The popular page itself should be produced by a background job every few minutes, never computed per request.

Notice what does not break: write throughput. At 200 writes per second, the primary database is bored. If growth ever multiplies writes by a hundred, shard bookmarks by user_id, and accept that tag pages then need the fanout-on-write path since they would cross shards.

Want to master this with video lessons and real case studies? This topic is covered in depth in my Udemy course System Design Fundamentals for Interviews — 5.5 hours, rated 4.8★, built from real interview questions.

How to Talk About This in an Interview

Here is a 30-second answer you can memorize and adapt:

"A bookmarking service is a read-heavy system, roughly 100 reads per write. My estimate is about 200 writes and 20,000 reads per second at peak, with storage around a terabyte a year, so the design centers on reads. I would model users, bookmarks, and tags with a join table for the many-to-many relationship, expose a small REST API, and serve reads through a cache-aside Redis layer backed by one primary and several read replicas. Tag pages are the interesting part: I would build them on read with short TTL caching, and precompute lists only for the hottest tags. The main failure modes are cache stampedes and hot counters, which I would handle with request coalescing and batched counts."

Then stop talking and let the interviewer pick the thread they care about. A crisp opening plus a pause beats ten minutes of unprompted detail every time.

Key Takeaways

• del.icio.us was a real social bookmarking service acquired by Yahoo; the interview question is a disguised test of read-heavy design.
• Do the estimation honestly: ~70-200 writes/sec, ~7,000-20,000 reads/sec, ~1.1 TB/year. The numbers tell you reads are the problem.
• The data model is a classic many-to-many: users, bookmarks, tags, and a bookmark_tags join table with the right indexes.
• Scale reads with cache-aside caching in front and primary-replica replication behind, accepting brief staleness.
• Handle tag-page fanout per tag: fanout on read for cold tags, precomputed lists for hot ones.

Next Steps

You have now designed a read-heavy system end to end. The next case study flips the pressure: a coding contest platform like LeetCode, where thousands of users submit code at the same instant, every submission must be judged in a sandbox, and a live leaderboard has to stay fair under a write-heavy burst. Read it next: Design a Coding Contest Platform (LeetCode).