For a user-centric app, which field typically serves well as a shard key?

For a user-centric app, which field typically serves well as a shard key?

• A. email addresses hashed.
• B. random_uuid.
• C. user_id.
• D. account_created_timestamp.

Answer: (C)

Choosing a shard key that matches how the app accesses data and distributes load evenly is the key idea. In a user-centric app, most operations revolve around a single user’s data—reading or updating that user’s profile, settings, or history. Using the user’s unique identifier as the shard key keeps all of that user’s data on the same shard, which minimizes cross-shard queries and makes routing predictable and efficient. If the IDs are generated to be roughly uniformly distributed (for example, UUIDs or Snowflake-style IDs), this also avoids hot partitions as the user base grows. Using an email hashed to a shard key could spread data well, but it doesn’t align with the common access pattern of looking up by user_id, and it adds complexity to translate between email-based lookups and the canonical user_id. Sharding by the account creation timestamp tends to load servers unevenly during signup bursts, creating hot spots. A random UUID as a shard key distributes data but undermines locality for user-specific reads and writes, leading to more cross-shard operations. So the user’s unique identifier is the best fit because it directly matches the primary access path and supports efficient, scalable routing.

Choosing a shard key that matches how the app accesses data and distributes load evenly is the key idea. In a user-centric app, most operations revolve around a single user’s data—reading or updating that user’s profile, settings, or history. Using the user’s unique identifier as the shard key keeps all of that user’s data on the same shard, which minimizes cross-shard queries and makes routing predictable and efficient. If the IDs are generated to be roughly uniformly distributed (for example, UUIDs or Snowflake-style IDs), this also avoids hot partitions as the user base grows.

Using an email hashed to a shard key could spread data well, but it doesn’t align with the common access pattern of looking up by user_id, and it adds complexity to translate between email-based lookups and the canonical user_id. Sharding by the account creation timestamp tends to load servers unevenly during signup bursts, creating hot spots. A random UUID as a shard key distributes data but undermines locality for user-specific reads and writes, leading to more cross-shard operations. So the user’s unique identifier is the best fit because it directly matches the primary access path and supports efficient, scalable routing.