Azure Event Hubs Scaling Guide: Throughput Units (TUs), Partitions, Auto-Inflate and Load Distribution

Azure Event Hubs is built for high-throughput, real-time data ingestion. To achieve this, you must understand how scaling works, especially Throughput Units (TUs), partitions, auto-inflate and load distribution between producers and consumers.

This guide breaks down everything in a simple, practical way.

1. Throughput Units (TUs) – The Core of Event Hub Scaling

A Throughput Unit (TU) defines how much data your Event Hub can handle.

More TUs = more ingestion + more reading capacity.

Per TU Capacity

Each 1 TU provides:

• Ingress: 1 MB/sec or 1000 events/sec
• Egress: 2 MB/sec or 4096 events/sec
• Brokered connections: 84 per second

These limits multiply with the number of TUs.

Example:

If you assign 4 TUs, your hub can handle:

• 4 MB/sec ingress
• 8 MB/sec egress
• 336 brokered connections

When to scale TUs?

Increase TUs if:

• Producer receives RequestRateExceeded errors
• Consumer throughput lag increases
• You see spikes in ingress MB/sec
• You need more parallel connections

2. Partitions – Parallel Lanes for Events

Partitions allow parallel consumption and distribution of events.

Why Partitions Matter

• Parallel processing: more partitions = more consumer instances
• Higher throughput: parallel writes to partitions
• Ordering: ordering guaranteed only within a single partition

Partition Count Rules

• You can only increase partitions (not decrease).
• More partitions = higher storage and parallelism.
• You cannot have more consumers than partitions in the same consumer group.

Choosing Partition Count

A simple guideline:

If unsure, choose more – partitions are cheap, and you can scale consumers later.

4. Producer Load Distribution – How Events Are Assigned to Partitions

Producers distribute events to partitions using two modes:

Mode A: Automatic Round-Robin (Default)

Event Hubs automatically cycles through partitions.

Useful when:

• Events are independent
• Ordering is not critical

Mode B: Partition Key

Sending with:

send_event(EventData(body), partition_key="device123")

Guarantees:

• All events with same key go to the same partition
• Ordering preserved

Best for:

• IoT devices
• Patient records
• Account/session-based events

Warning:

Using a bad partition key (e.g., same key for all events) → overloading one partition → hot partition → reduced throughput.

5. Consumer Load Distribution – How Partitions Are Balanced

Consumers in a consumer group must divide partitions among themselves.

Rules:

• One consumer instance can own one or more partitions
• A partition can be owned by only ONE consumer instance
• If consumers > partitions → extra consumers stay idle

Example:

4 partitions, 2 consumers:

Consumer 1 → P0, P1
Consumer 2 → P2, P3

Add two more consumers:

Consumer 1 → P0
Consumer 2 → P1
Consumer 3 → P2
Consumer 4 → P3

6. How to Scale Event Hub Like a Pro

Increase Partitions for Parallel Consumption

If you need:

• More consumer instances
• Parallel processing
• Fine-grained partition keys

Increase partitions (e.g., from 4 → 8).

Increase TUs for Higher Ingestion/Egress

If you need:

• More MB/sec ingestion
• More events/sec
• More concurrent connections

Increase TUs (e.g., from 3 → 6).

Enable Auto-Inflate for Bursty Traffic

Useful when:

• Traffic fluctuates
• You ingest telemetry/logs
• You don’t want manual TU scaling

Use Proper Partition Keys

Ensure even distribution.

Good:

• deviceId
• patientId
• accountId

Bad:

• timestamp
• region
• a constant value

Add More Consumer Groups for Multiple Independent Pipelines

Each consumer group gets a separate view of the partitions.

Use cases:

• Analytics consumer
• Monitoring consumer
• ML pipeline consumer

7. Common Scaling Mistakes to Avoid

• Too few partitions → consumer bottleneck
• Too few TUs → producer throttling
• Wrong partition key → hot partition
• More consumers than partitions → idle consumers
• Expecting auto-inflate to scale down → it doesn’t

Summary Table – What Scales What?

Related Searches

• Modernizing Healthcare Data Integration with Azure Event Hubs – OpsTree
• Azure Event Hubs Explained for Real Time Data Streaming
• Event Hub vs Confluent Cloud: Which One Should You Use and When?

Related Solutions

• Data Engineering Solutions
• Cloud Migration Services
• Data Engineering Services and Solutions companies