Design a comment system

Question 1

Who is posting and who is reading?

Accepted Answer

Almost everybody reads and almost nobody posts. Both paths start at the same client, and they need very different treatment behind it.

Question 2

What does the page talk to?

Accepted Answer

A service is where a comment gets attributed to a signed-in user, rate limited, and checked for length before it becomes a row.

Question 3

Where do comments live?

Accepted Answer

Comments are small, relational — article, author, parent comment — and always queried the same way: newest first for one article. That is a database with an index on (article, created_at).

Question 4

An article hits the front page. Everybody loads the same twenty comments. What are you querying?

Accepted Answer

The first page of a hot thread is the same answer for every reader for minutes at a time. Cache the rendered page of comments and invalidate it when a new one arrives — that turns 11,600 queries a second into a handful.

Question 5

Every comment needs a spam check that takes 300ms. Does the poster wait?

Accepted Answer

No. Accept the comment, enqueue the check, and hide it later if it fails. Putting a slow third-party call inside the write means an outage there is an outage here.

Question 6

Your client writes to the comments store directly. What stops it posting as someone else?

Accepted Answer

Authorship, rate limits and moderation state are all decisions. A browser with a connection to the database makes none of them.

Question 7

How many comment reads a second are you serving?

Accepted Answer

20M writes a day at 50:1 is 1B reads a day, or about 11,600 a second. Next to ~230 writes a second, that is what says to spend the effort on the read path and nowhere else.

Blueprint — system design