A crane-meadow Event Hub has 32 partitions and still throttles on ingress. What should the developer raise instead of only adding partitions?
Select an answer to reveal the explanation.
Short Explanation
Partitions slice the log; they are not free ingress quota. Raise throughput units — or processing units on Premium — when the namespace still throttles with plenty of partitions.
Full Explanation
Partitions increase parallelism and define ordering keys for a crane-meadow Event Hub, but they do not by themselves grant more ingress or egress capacity. When the hub still throttles with plenty of partitions, the developer must raise namespace capacity—throughput units on Standard or processing units on Premium—so the broker can accept the offered load. Capacity planning therefore separates "how work is sliced" from "how much bandwidth the namespace is allowed to move."
Microsoft Graph permission scopes on the hub namespace fail because Graph OAuth scopes do not provision Event Hubs ingress quota. Relying on Blob soft-delete retention on the checkpoint container alone fails conceptually: soft-delete protects blobs from accidental deletion; it does not increase Event Hubs throughput. Scaling an AKS node pool when the app is not on Kubernetes fails because compute for an unrelated platform cannot substitute for Event Hubs namespace TU/PU limits.
Exam caveat: after raising units, hot partitions can still throttle a single key even when the namespace has spare aggregate capacity—review partition key distribution if one key absorbs most traffic. Operational check: watch throttled request metrics while load testing, increase TUs or PUs, and confirm ingress succeeds without sustained 429/throttle signals at the prior rate.