Learner completed Lesson 1 (partitions: ordering, parallelism, locality). Demonstrated understanding: same-key → same-partition routing; ordering guaranteed within a partition only; global order requires one partition; skip-not-block retry trade-off; state-per-partition with changelog-backed durability and replay-on-rebalance; consumer-group ownership (one consumer per partition per group); the raw-record shape (key/value/offset/partition/timestamp) and that the log lives on the broker. Connected partitioning to their own dedup/reconciliation work ("exactly-once becomes a local problem").
Misconception corrected (high value): the hot-key problem is skew (unbalanced load), not CPU cost. Learner initially proposed "just use user_id" as a fix — which is identical routing to hash(user_id). Standard fix: salting for order-tolerant messages (marketing), which trades ordering for balance; keep co-location where order matters (transaction alerts). Recurring pattern: every partitioning decision is the order-vs-parallelism/balance trade-off (Rule 1).
Implications: next lessons in priority order — (2) failure/chaos testing, (3) estimation reps. Learner learns best through concrete "your-own-system" examples and correct-by-honest-grade feedback.