A partition key (or shard key) is the field a distributed database or stream uses to decide which partition each record belongs to — all records with the same key land together. It determines how data and load spread across nodes.
Worked example: partitioning orders by customer_id keeps a customer’s orders together (good for per-customer reads) but a whale customer can overload one partition — a hot partition; partitioning by a high-cardinality key like order_id spreads load evenly but scatters per-customer queries. Gotcha: the partition key is hard to change later (it dictates physical layout), and low-cardinality or skewed keys create hotspots — choose it around your dominant access pattern, and add compositing or randomness if one value would dominate.