DBRaven
Failure Mode · capacity

Slow Consumer

partial

Summary

A single consumer instance in a Kafka consumer group processes messages significantly slower than its peers, causing partition lag to accumulate on its assigned partitions and triggering consumer group rebalances that temporarily suspend all partition consumption.

Description

Kafka consumer groups assign each partition to exactly one consumer instance. If a consumer group has 4 consumers and 8 partitions, each consumer handles 2 partitions. If consumer C3 processes messages at half the rate of C1, C2, and C4, the partitions assigned to C3 accumulate lag while others drain normally. The system appears partially degraded: overall consumer group lag grows even though 75% of consumers are performing normally.

The slow consumer condition is often caused by: JVM garbage collection pauses (a Full GC taking 5–30 seconds causes the consumer to miss heartbeats); a downstream dependency specific to one consumer instance's environment (a degraded local database connection, a misconfigured connection pool); or an uneven work distribution where certain partitions contain computationally expensive messages.

The failure worsens through rebalances. Kafka consumers send heartbeats to the group coordinator every heartbeat.interval.ms (default 3 seconds). If a consumer does not send a heartbeat within session.timeout.ms (default 45 seconds for modern Kafka clients, 30 seconds in older versions), the group coordinator evicts the consumer and triggers a rebalance. During a rebalance, all consumers in the group stop processing messages: assignment is revoked from all consumers simultaneously. The rebalance protocol (JoinGroup, SyncGroup round-trips) takes 3–30 seconds depending on group size and broker load. During this window, no partition in the group is being consumed; lag grows at the full produce rate across all partitions.

A slow consumer that misses heartbeats due to GC pressure will repeatedly trigger rebalances: slow → GC pause → miss heartbeat → eviction → rebalance → all consumers stop → GC eases → consumer rejoins → rebalance → resume → slow again. This creates a rebalance loop where the group spends more time in rebalance than in productive consumption.

Characteristics

Propagationisolated
Time to detect2–10 minutes with per-partition lag monitoring. Rebalance events are detectable within seconds in Kafka broker metrics. The root cause (GC on a specific JVM) may take longer to identify if consumer-instance-level metrics are not available.
Blast radiusWithout cooperative rebalancing, the blast radius is the entire consumer group: all partitions stop consuming during each rebalance event. With cooperative rebalancing, only the affected partitions are reassigned and others continue. Lag accumulates on the slow consumer's partitions; downstream systems receiving data from those partitions fall further behind. If the slow consumer causes repeated rebalances (GC loop), the effective throughput of the entire group drops significantly.

Triggers

  • ·JVM Full GC pause on one consumer exceeding session.timeout.ms (default 45s)
  • ·Downstream database or API degraded only for the specific consumer instance's connection
  • ·CPU throttling on the container hosting one consumer instance (K8s CPU limits)
  • ·Uneven partition content: one partition contains unusually large messages or expensive-to-process records
  • ·Consumer processing a poison-pill message that causes slow retry loops

Detection Signals

queue depthalertlatency spikedisk saturationlog errors

Mitigation Strategies

Enable cooperative incremental rebalancingcomplexity: low

Configure partition.assignment.strategy = CooperativeStickyAssignor in all consumers. Cooperative rebalancing only revokes and reassigns affected partitions instead of stopping all consumers. A single slow consumer's partitions are reassigned without pausing the rest of the group.

Tune JVM GC to prevent pauses exceeding session.timeout.mspreventscomplexity: medium

Configure G1GC or ZGC with a max pause time target below heartbeat timeout: -XX:MaxGCPauseMillis=500 and session.timeout.ms=10000. ZGC achieves <10ms pauses for most heap sizes. Alternatively, increase session.timeout.ms to 120,000ms to tolerate longer GC pauses, accepting slower eviction of truly failed consumers.

Configure max.poll.interval.ms to match actual processing timepreventscomplexity: low

If processing time per poll batch is legitimately long (e.g., batch calls to an external API), set max.poll.interval.ms to the maximum acceptable processing time. Default is 5 minutes; if processing takes 8 minutes per batch, the consumer will be evicted. Increasing this value prevents false evictions but delays detection of truly stuck consumers.

Limit consumer prefetch (max.poll.records)complexity: low

Reduce max.poll.records (default 500) to limit the number of messages fetched per poll. Smaller batches mean shorter processing windows per poll cycle, reducing the risk of exceeding max.poll.interval.ms due to a large batch of slow messages.

Recovery Steps

  1. 1.Identify the slow consumer instance: compare per-instance metrics or per-partition lag to find the outlier
  2. 2.Check JVM GC metrics for the slow instance: full GC frequency and duration
  3. 3.If GC is the cause: restart the consumer instance (eviction forces partition reassignment to faster instances)
  4. 4.If downstream dependency is the cause: fix the dependency on the affected instance or migrate partitions manually
  5. 5.After immediate recovery: enable cooperative rebalancing and tune GC settings to prevent recurrence
  6. 6.Consider adding consumer instances to reduce per-instance partition count, providing headroom for temporary slowness

Estimated recovery time: 2–10 minutes once the slow consumer instance is identified and restarted or replaced. With cooperative rebalancing, partition reassignment completes without stopping other consumers. Without it, each rebalance adds 3–30 seconds of group-wide stoppage.

Affected Systems

Patterns

event sourcingcqrsoutbox patterncompeting consumers

Technologies

kafka

Basis

Precisely understood Kafka consumer group mechanics; GC pause and rebalance loop failure modes are well-documented with exact parameter thresholds

Run This Failure

Blast radius analysis for this failure mode within each scenario that carries it.

Related Architecture Knowledge

Outbound: this entity affects

Introduces RiskFailure Mode
queue backlog accumulation
Grounded

A slow consumer processing messages below the producer rate causes queue backlog to accumulate. If processing speed does not recover, backlog grows unboundedly, eventually causing either message loss (if the queue has a depth limit) or indefinite processing delay.

Tradeoffs

  • ·Increasing consumer parallelism helps only up to the partition count (Kafka) or queue message visibility limit (SQS)
  • ·Speeding up per-message processing (optimization) has a multiplicative effect on throughput recovery
  • ·Backlog recovery after a slow consumer incident may require priority processing of newest messages first
Full relationship →

Inbound: affects this entity

MitigatesPattern
backpressure
Draft · unverified

Backpressure prevents slow consumers from falling further behind by signaling producers to pause, giving the consumer time to drain its backlog before new messages arrive.

Full relationship →

Used In Architecture Scenarios

AI Retrieval-Augmented Generation Platformhigh

AI / RAG Application

A Retrieval-Augmented Generation (RAG) architecture that combines vector similarity search for semantic document retrieval with relational metadata filtering, using PostgreSQL with pgvector as the unified store for both embeddings and structured data. Redis provides a semantic cache to avoid redundant embedding model inference and reduce vector index query load for repeated or similar queries. Kafka manages the asynchronous embedding generation pipeline that keeps the vector index current as source documents are added or updated.

Analytics Data Platformhigh

Analytics Pipeline

An OLAP-oriented analytics architecture that ingests operational changes from PostgreSQL via WAL-based CDC into Kafka, then routes them to a columnar analytics store (ClickHouse or Snowflake) for product analytics, business intelligence, and operational reporting. The CQRS separation ensures analytical queries never degrade transactional write performance, and materialized views provide pre-aggregated query acceleration for the most expensive analytical patterns.

Developer Tools Platformhigh

Multi-Tenant SaaS

A multi-tenant developer tooling platform providing CI/CD pipeline execution, log aggregation, code analysis, and dependency scanning across isolated tenant organizations. Tenant isolation is the primary correctness constraint: a security boundary violation between tenants is a critical incident, not a performance event. PostgreSQL row-level security enforces data isolation; Redis manages job queues and distributed locks; Elasticsearch indexes pipeline log output for search; Kafka delivers webhook events to tenant-registered endpoints; MinIO stores pipeline artifacts. Resource quota enforcement prevents any single tenant's burst from affecting others.

Distributed Job Queue Platformmoderate

Write-Heavy Application

A durable background job execution platform where jobs are enqueued via API and executed by competing consumer worker pools. PostgreSQL is the durable job store, job definitions, retry state, scheduling metadata, and dead-letter records persist in PostgreSQL with ACID guarantees, surviving any worker or queue infrastructure failure. Redis tracks in-flight job state (which worker claimed which job, visibility timeout lease expiry) to enable fast lease checks without PostgreSQL queries on the hot path. Temporal provides workflow orchestration for multi-step jobs that require coordination across multiple execution stages, with built-in state machine semantics and durable activity execution. Kafka carries job completion events to downstream consumers (analytics, billing triggers, notification fan-out). Backpressure between the job enqueue rate and worker execution rate prevents runaway job accumulation when workers are degraded.

Geospatial Tracking Platformhigh

Realtime Collaboration

A real-time location tracking platform for moving entities: vehicles, delivery couriers, field workers, and assets: receiving position updates at 1–30 second intervals from thousands of simultaneously tracked objects. Redis geospatial indexes (GEOADD / GEOSEARCH) serve sub-10ms proximity queries against the live position surface; PostgreSQL stores durable entity metadata and historical location records; TimescaleDB stores high-frequency time-series location data with automatic hypertable chunking and retention policies; Kafka streams location events to downstream consumers (dispatch systems, customer tracking apps, analytics pipelines). Geofence evaluation runs at ingestion time: each incoming position update is tested against active geofences for the entity's region, and geofence entry/exit events are emitted as Kafka messages to downstream consumers.

IoT Telemetry Ingestion Platformhigh

Write-Heavy Application

A high-rate device telemetry ingestion architecture designed for millions of devices emitting metrics at 1–60 second intervals. Kafka absorbs device writes as an ingestion buffer, decoupling device-facing ingest endpoints from the storage write path so that downstream storage pressure never propagates back to devices. TimescaleDB provides time-series storage with automatic chunk partitioning by time range, native compression, and continuous aggregate views for rollup queries. ClickHouse serves as the OLAP layer for device fleet analytics queries. Redis caches last-known device state (current readings per device) for real-time alerting queries that must not scan historical storage. Backpressure on the Kafka consumer side prevents storage write throughput from being overwhelmed by burst ingestion events from device reconnect storms.

ML Feature Serving Platformexpert

AI / RAG Application

A low-latency feature serving platform for ML model inference, providing both batch (offline) and real-time (online) feature access with strict training-serving consistency. Redis serves the hot feature cache with p99 latency targets below 5ms for online inference requests; PostgreSQL provides point-in-time feature lookups for offline training jobs with temporal consistency guarantees; Cassandra stores high-cardinality feature entities at write scale beyond PostgreSQL's single-primary ceiling; Kafka streams feature computation events from online feature pipelines to update the cache; Qdrant stores vector features for embedding-based model inputs and similarity lookups; ClickHouse serves feature analytics and drift monitoring across training dataset populations. Feature versioning is first-class: every feature value is tagged with a pipeline_version and computed_at timestamp to support model reproducibility and training-serving skew diagnosis.

Notification Delivery Platformmoderate

Event-Driven System

A multi-channel notification delivery architecture that accepts upstream business events (order placed, payment received, comment posted, threshold alert triggered) and routes them to per-channel delivery workers (push via FCM/APNs, email via SendGrid, SMS via Twilio, in-app via WebSocket). Kafka carries raw business events from upstream producers. RabbitMQ handles per-channel fan-out with separate exchanges and queues per delivery channel, isolating email queue backlog from push notification delivery. PostgreSQL provides durable notification state tracking (sent, failed, bounced, suppressed). Redis enforces per-user rate limiting (notification frequency caps to prevent fatigue) and stores deduplication tokens to prevent duplicate sends across retry attempts. The inbox pattern on the consumer side ensures idempotent delivery even when Kafka produces duplicate events.

Observability Platformhigh

Analytics Pipeline

A metrics, logs, and traces ingestion and query platform built to absorb the telemetry output of a production system fleet: including the telemetry volume spikes that accompany the incidents the platform is meant to detect. ClickHouse stores metrics data with automatic time-based rollup via continuous materialized views; TimescaleDB provides complementary time-series storage for high-cardinality alert evaluation; Kafka buffers the ingestion stream against downstream write pressure, decoupling ingest acceptance rate from storage write throughput; Elasticsearch serves log full-text search and structured field filtering; Redis caches dashboard query results and active alert state for sub-100ms alert evaluation latency. The alert engine evaluates threshold and anomaly rules against pre-computed materialized views, not raw data, to bound alert evaluation cost independent of ingestion volume.

Streaming Media Platformhigh

Event-Driven System

A video and audio streaming architecture where content ingestion triggers an async multi-variant transcoding pipeline, CDN delivery handles 95%+ of playback traffic, and Cassandra absorbs the write volume of per-user viewing history. Kafka decouples upload events from transcoding workers; MinIO stores raw and encoded assets; Redis maintains playback session state and view counters. The architecture must handle upload spikes without blocking delivery, and cache cold starts without cascading database load.