AT1 — Consistency/Availability: Hash partitioning distributes load evenly but eliminates range query capability entirely. To answer “find all users created between date A and date B” on a hash-partitioned table, you must fan out to every shard and merge results. Range partitioning preserves query expressiveness at the cost of potential hot shards. The choice is not between good and bad — it is between two different constraints: query flexibility and write distribution cannot be maximised simultaneously with a single partitioning key.
AT5 — Centralisation/Distribution: The routing map that directs each request to the correct shard is itself a scaled component. Centralising it (ZooKeeper, a config server, a dedicated routing service) provides a single authoritative source of truth but introduces a coordination bottleneck and a single point of failure. Distributing it (embedding the routing table in client libraries, gossip protocols) removes the bottleneck but means routing tables can diverge temporarily across clients. DynamoDB uses a centralised routing tier. Cassandra gossips the ring state to all nodes and embeds routing in the client driver. Neither approach is wrong — the tradeoff is operational simplicity versus resilience to coordinator failure.