The writes are spread evenly. Why does one customer's history need 80 queries?

An even hash does not preserve the query you care about

You can hash each event_id to spread inserts evenly. It is simple and works well for direct reads when you know the ID. But consider the request “Give me customer T42's events between 09:00 and 10:00, sorted by time.” Events from T42 are scattered across many partitions. The query may fan out to all 80 shards and merge results. Its latency depends on the slowest participants, and each new partition adds coordination work.

At the other extreme, you can store every customer's events together, ordered by (customer_id, event_time). The customer's range scan becomes efficient. The catch is a whale tenant. If one customer produces 40 percent of writes, its contiguous range may be served by one physical unit of capacity even though hundreds of smaller customers are spread nicely.

Neither layout is universally correct. Measure the mix of access patterns, scan sizes, and whether point lookups can tolerate an index hop.

Use a customer prefix, then order within it

A common starting point is to hash the customer identifier for broad placement, then maintain records in a local ordered structure under that customer. Logically the key is (tenant_id, timestamp, event_id). The tenant portion routes the operation, while the ordered suffix supports range scans without looking at unrelated tenants.

The stable event ID breaks ties between events with identical timestamps and supports repeatable pagination. If the caller needs the same results after new events arrive, its pagination contract must define whether it reads from a fixed snapshot or advances through a changing stream. Sorting by timestamp alone is not enough for a total order when clocks disagree or events share timestamps.

DynamoDB explicitly distinguishes a partition key from a sort key and uses the sort key to support range queries within a partition-key value. Bigtable instead emphasizes designing lexicographically ordered row keys around prefix and range scans. Those are related design principles, not identical implementations. DynamoDB sort-key guidance and Bigtable schema design.

The ID lookup now needs attention. Either the client already knows the tenant, the event ID encodes enough routing information, or you maintain a separate index from event ID to the owning tenant and location. That extra index has its own consistency and recovery behavior. An answer that delivers perfect time scans by silently abandoning point lookups has not solved the original problem.

A large customer may need several physical ownership ranges

For moderate tenants, one tenant-level group may be a good fit. For a customer accounting for 40 percent of writes, consider bounded time buckets, such as (tenant_id, day) as a routing unit. Historical days become relatively cold, and independent days can be placed separately. A week-long request becomes seven range queries and a merge, which is often an acceptable price for distributing the data and simplifying retention.

But daily bucketing does not automatically spread today's live writes. All of today's inserts may still target the current bucket. If that bucket exceeds a partition's capacity, split it further with a sub-bucket derived from a stable property, or by explicit range ownership. A query for that day must then query the relevant sub-buckets and merge their ordered results.

For example, four sub-buckets could each receive one quarter of this customer's writes under a good assignment. That is a capacity hypothesis to verify, not a guarantee. If events must be processed in one strict acceptance order, independently accepting writes into four buckets introduces another question: who assigns the order and how does a reader recover it? A timestamp sort is only chronological ordering according to the timestamp's semantics, not proof of one globally serialized acceptance sequence.

Bigtable warns against a timestamp-first row key because monotonically increasing prefixes can concentrate writes on one tablet. Appending a timestamp after a well-distributed prefix is better for broad distribution, but even that can leave a single extremely active prefix hot. Bigtable schema best practices.

Leave yourself a way to change placement

Do not bake the partition count into permanent event IDs if a later reshard would force clients to reinterpret them. Treat physical placement as versioned metadata that can evolve while event identity stays stable. Document whether a customer is routed as one unit, by day, or by day and sub-bucket.

Measure per-tenant write share, hottest physical partition, query fanout, merge cost, and the number of active ranges per tenant. Once a tenant's layout changes, range readers must understand both historical and new layouts until backfill or a stable directory makes them uniform.

You have designed a partition key that supports useful reads. What happens when the one tenant that was small last year now needs to move to a different database while writes continue? The data layout is only half the migration. The other half is who is allowed to accept the next write.