Detailed Design of Sharded Counters

Detailed design

Use a hypothetical tweet-like service to work through counter creation, updates, and reads. The design is an exercise, not a description of Twitter/X’s internal implementation. Resolve these questions:

• How many shards should be created against each new tweet?

• How will the shard value be incremented for a specific tweet?

• What will happen in the system when end users issue read requests?

Sharded counter creation

When a user posts a tweet, the createCounter API is called to create multiple counters for that tweet, such as:

• Like counter

• Reply counter

• Retweet counter

• View counter (for video tweets)

A core design decision is choosing the number of shards per counter. The shard count directly impacts write contention and read amplification. Too few shards increase write contention and throttle throughput. Too many shards increase read amplification because the system must fetch and aggregate values across multiple shards, potentially spanning nodes or regions. Increasing shard count can increase write capacity until shared storage, routing, or network resources become limiting. Read aggregation and coordination costs also grow. This creates a fundamental trade-off between write scalability and read performance.