Blogging Platform System Design

The interviewer's prompt sounds like something you could install on a Friday afternoon: "Design a multi-user publishing platform like Medium. Every writer gets a personal publication where they draft, edit and publish posts; readers read those posts, follow the publications they like, and get a feed of new posts from them. Assume tens of millions of readers."

The first version writes itself: a posts table, a rich-text box with a save button, and a page that runs SELECT * FROM posts WHERE id = ? on every view. It works for one writer. Now meet Maya, a backend engineer in Toronto who writes a publication called Boring Infrastructure for 40,000 followers. She drafts "Postgres Is Enough for Your Startup" over three evenings, half on her laptop and half on her phone on the streetcar. The editor saves her work roughly 540 times, and it must never lose a sentence, even when the phone was offline and the laptop moved on without it. She publishes on a Tuesday at 9:00 a.m. By 10:15 the post is on the front page of Hacker News and pulling 5,000 views a second. At 10:20 she spots a typo in the second paragraph and fixes it. Daniel, opening the post in Berlin ten minutes later, has to see the corrected sentence, and the database must not notice the 5,000 readers at all.

The Trap Built Into "It's Just a Blog"

Two failures come up again and again:

• The WordPress Install: one database, every page rendered per request, a "Save draft" button, and no arithmetic. Signal: never noticed that readers outnumber publishes about a thousand to one, that nearly all of those reads are cacheable, or that the editor (not the publish button) carries almost all of the write traffic.
• The Twitter Clone: treats the prompt as a social feed problem and spends forty minutes on fan-out, while the editor that writers trust with their words and the read path that serves 100 million article views a day get one box each. Signal: pattern-matched the prompt instead of reading it.

The passing answer sees two systems wearing one logo. One is a durable writing tool for 500,000 daily writers, where autosave outnumbers publish about 450 to one and an acknowledged save must never be lost. The other is a read-mostly publishing network for 25 million daily readers, where the CDN is the architecture: one cached HTML page per post for everyone, a 24-hour TTL, and an event-driven purge that gets Maya's typo fix to every edge in under a minute. They share one idea in the data model: a post is a mutable draft, a chain of immutable revisions, and a single pointer that says which revision readers see. Publishing is flipping that pointer.