Comment trees - one range scan, and four writes per vote

Clarifying questions to ask first

• How deep can a thread go, and may we cap it? A cap turns an unbounded recursive problem into a bounded one, and the product usually accepts it.
• Are scores exact or approximate? "Approximately 4.2k" is a product decision that buys an enormous amount of engineering freedom.
• Must a user see their own vote and their own comment immediately? Almost always yes, and it is the one consistency promise worth keeping.
• How much traffic is logged out? On a link aggregator it is typically 70-80%, and that traffic is identical for every viewer, which means a CDN can absorb it. This single answer changes the origin load by 4x.
• Can a moderator move or remove a subtree, and what happens to its children? This decides whether materialized paths are viable.
• Is vote manipulation in scope? Storing every individual vote is required to prevent double-voting, and it is also the largest table in the system.

Functional

• Read a thread: a ranked, paginated, nested tree of comments.
• Sort by best, top or new; each is a different tree over the same rows.
• Post a comment as a reply to the post or to another comment.
• Vote on a comment or a post, once per user per thing, changeable.
• Collapse and expand subtrees; load more of a deep thread on demand.

Non-functional

• Thread read p99 under 300 ms at the origin, and under 50 ms at the edge for logged-out readers.
• A comment is visible to its author immediately and to everyone else within 2 seconds.
• Vote counts may be up to 30 seconds stale and may be approximate. This is stated as a requirement, not conceded as a bug.
• 99.95% availability on reads; writes may be less available.
• A user must never be able to vote twice, even across a failover. This is the one hard consistency requirement on the board.

Explicitly out of scope

Moderation tooling, spam detection, the ranking model itself, notifications, and the subreddit feed. The ranker is one box.