Questions
5 of 5
Basics
Cluster Architecture
Topics, Partitions and Records
Producers
Consumers
Consumer Groups
Offset Management
Replication and Fault Tolerance
Storage Internals
Networking and Request Processing
Performance and Throughput
Delivery Semantics
Transactions
Kafka Streams
Kafka Connect
Schema and Serialization
Security
Error Handling and Retry Patterns
Ordering and Partitioning Design
Testing
Monitoring and Observability
Debugging and Troubleshooting
Deployment and Operations
Admin and CLI Operations
Reliability and Disaster Recovery
Integration Patterns
Modern Kafka Architecture
Advanced Internals
Scalability and Capacity Planning
Architecture and System Design
Production Best Practices
Expert Edge Cases
Versioning and Upgrades
Admin and CLI Operations
Senior End-to-End Scenarios
Difficulty: 9/10
Reliability and performance
Key by the finest ordering unit, give each tenant a configurable spread across partitions, and isolate the largest tenants entirely
I start by asking what ordering is actually needed. Almost never is it per tenant. It is per entity inside a tenant (per user, order, device, or aggregate). That distinction is what frees the design. If I key by tenantId alone, a large tenant is pinned to one partition and one consumer, which is the hot partition problem. If I key by the entity within the tenant, load spreads, per-entity ordering is preserved, and tenant-level ordering is given up, which the business usually does not need. So the baseline is a composite key such as tenantId:entityId, with the partitioner designed so a tenant's traffic lands on a controlled set of partitions.
Tenants are not uniform, so I use tiers. Small tenants (the long tail) share a pool topic and hash to one partition by tenant, which keeps their footprint small and preserves tenant-level ordering if someone cares. Medium tenants are spread across a bounded number of partitions, a bucket count B per tenant, by hashing the entity ID inside that range. Very large tenants get a dedicated topic (or a dedicated cluster for regulated or extreme cases), which gives isolation: their own partitions, retention, quotas and consumer group, so their spikes and lag cannot affect others. Tenants are promoted between tiers by measured throughput, not by sales promises. Capacity planning then becomes per tier: partitions are sized for the tier's aggregate peak, and quotas per client or user stop one tenant from monopolizing broker bandwidth.
javascript
- 1
Ordering trade-off: per-entity ordering is kept, tenant-wide ordering is not for tenants with buckets above 1. Make that contract explicit in the tenant-event documentation.
- 2
Changing a tenant's bucket count remaps its entities, so ordering can break across the change boundary. Treat bucket changes as a controlled migration: version the config, drain or fence in-flight events, and change during low traffic, or move the tenant to a new topic.
- 3
All producers for the topic must share the same partitioner logic and config version. A mismatch silently breaks ordering and locality, so ship the partitioner as a shared library with contract tests.
- 4
Isolation: dedicated topics for large tenants cost more partitions and operations, but give independent retention, quotas, lag alerting and blast radius. Pick the threshold from measured share of traffic and SLA, not from a fixed number.
- 5
Fairness and capacity: apply produce and fetch quotas per principal or client-id so one tenant cannot saturate broker network. Monitor per-tenant bytes in, per-partition skew and consumer lag by tenant.
- 6
Consumer side: large tenants need enough consumers per partition window. Consider a key-aware worker pool inside a consumer if per-partition processing is the bottleneck.
- 7
Alternative: one topic per tenant. It gives the cleanest isolation and per-tenant retention and ACLs, but breaks down with thousands of tenants because of partition and metadata overhead, so I use it only for the top tier.
- 8
Common mistake: adding partitions to fix a hot tenant when the key is tenantId. The tenant still hashes to one partition. Another is salting randomly with no entity affinity, which destroys per-entity ordering unnecessarily.
- 9
Version note: KRaft (the only mode from Kafka 4.0) raises practical partition limits compared with ZooKeeper-era guidance, but dedicated-topic-per-tenant designs should still be load-tested on your version and hardware.
Scenario Questions
0-2 years experience
2-5 years experience
- 1Product says tenant events must be in order, but when asked, the real need is per-user order. How does that discovery change your key and what do you tell stakeholders about the trade-off?
- 2You need to give a large tenant 8 partitions' worth of capacity without moving it to its own topic. Sketch how the partitioner chooses a partition and what ordering survives.
5-8 years experience
- 1A medium tenant's bucket count must increase from 4 to 16 because of growth. Describe the migration plan, what can go wrong with ordering and in-flight data, and how you validate it.
- 2One noisy tenant's replay job saturates broker bandwidth and other tenants see higher latency. Which controls (quotas, topic isolation, scheduling) do you apply and how do you verify the effect?
8+ years experience
- 1You serve 5,000 tenants with a long-tail distribution and strict per-tenant data residency for some. Propose the topic, cluster and partitioning topology, the promotion rules between tiers, and the metrics that drive them.
- 2Finance wants per-tenant cost attribution and security wants per-tenant ACLs, while platform wants fewer topics. Resolve the conflict between topic-per-tenant and shared-topic designs with a decision framework and an honest statement of what each option costs.