What is the primary benefit of a worker pool over spawning a new process per task?

Worker pools limit concurrency by fixing worker count, preventing resource exhaustion. Spawning per-task leads to uncontrolled resource consumption.

Which of the following is NOT a core component of a worker pool system?

Worker pools consist of queue, workers, and ACK/NACK. Caching is optional and orthogonal to the pattern.

In a worker pool, how is concurrency controlled?

The number of workers directly determines concurrency. N workers can process at most N tasks in parallel.

What does 'in-flight' status mean for a message in a queue?

In-flight means a worker has dequeued the message, making it invisible to prevent other workers from claiming it.

When should a worker send NACK instead of ACK?

NACK signals failure and requeues the task. ACK signals success and deletes it. Only NACK on actual failures.

What is the correct order of the worker infinite loop?

Worker must first dequeue a task, process it, then acknowledge. No other order is valid.

If a worker crashes after dequeuing but before NACK, what happens to the task?

The queue's visibility timeout protects against worker crashes by auto-requeuing if ACK/NACK not received in time.

Why must the dequeue operation hide the message from other workers?

Hiding prevents multiple workers from dequeuing the same message and executing duplicate work.

For a CPU-bound task on an 8-core server, how many workers should you provision?

CPU-bound work should have ~1 worker per core. More workers cause context-switching overhead.

For an I/O-bound task with 90% wait time on an 8-core server, approximately how many workers?

Formula: workers = cores × (1 + wait_time/work_time). With 90% wait: 8 × 10 = 80 workers.

Which task type allows the highest worker-to-core ratio?

I/O-bound tasks allow many workers because CPU is idle during waits. CPU-bound needs only 1 worker per core.

What happens if you provision too many workers for a CPU-bound task?

Excessive workers on CPU-bound work cause context switching. OS spends time switching instead of computing.

A task spawns 5 database queries sequentially, each taking 100ms on a single-core machine. What is the wait/work ratio?

DB-bound work waits on query responses; 500ms wait across entire task. Worker count tuned empirically between CPU and I/O formulas.

When a worker receives SIGTERM, what should happen immediately?

First action is to stop accepting new work. In-progress tasks are drained before exit.

What is the purpose of a shutdown grace period (e.g., 30 seconds)?

Grace period allows orderly shutdown. After timeout, process is force-killed to prevent hanging deployments.

During graceful shutdown, what must happen to in-flight messages before the worker exits?

Worker must explicitly ACK/NACK all in-flight tasks. Unacknowledged tasks stay in-flight until timeout.

If a task takes 45 seconds but the grace period is 30 seconds, what should happen?

Grace period is a hard deadline. Long-running tasks risk termination. Design with reasonable grace periods.

Why is resource cleanup (closing DB connections, file handles) important during shutdown?

Unclean shutdown leaves connections/handles open. Repeated deployments exhaust system limits.

Why use separate queues for push, email, and SMS notifications instead of one shared queue?

Separate queues enable tuning worker count per channel based on throughput and cost (push > email > SMS).

In a notification system, what is 'at-least-once delivery' and why accept it?

At-least-once with idempotency is reliable without complexity of exactly-once. Duplicates are tolerable.

How should a notification system handle downstream provider rate limits (e.g., FCM returns 429)?

Backoff gives provider time to recover. Increasing workers worsens throttling.

What happens if a critical alert notification exceeds max retries in a notification system?

Dead letter queue captures failed-after-retries tasks. Alerts monitor DLQ for critical notification failures.

In a notification system, why is idempotency important for retried notifications?

Without idempotency, a retry could duplicate delivery. Idempotency key ensures safe retries.

In the animation pipeline (upload → analysis → render → encode → deliver), which stage is likely CPU-bound?

Rendering frames and video encoding consume CPU. Upload/deliver are I/O-bound. Analysis is GPU-bound.

If the render stage (CPU-bound) is much slower than the upload stage (I/O-bound), what happens?

Downstream bottleneck propagates upstream. Filled render queue blocks upload queue from dequeuing.

In the animation pipeline, why use separate queues between stages instead of a single queue?

Stage queues decouple rates. Slow render won't block fast upload. But they enforce stage ordering.

If the animation app has a single GPU shared by all AI analysis workers, what is the main risk?

Unmanaged GPU sharing causes context switching and poor throughput. Kubernetes device plugins or task queueing required.

If video encoding fails mid-way through the animation pipeline, how should the system handle it?

Retrying requires idempotent upstream stages. Otherwise, retry produces different inputs (e.g., duplicate frames).

What is 'backpressure' in the animation pipeline and why is it important?

Without backpressure, slow render causes upload queue to fill unboundedly, exhausting memory.

For a 16-core GPU server, how would you size workers across heterogeneous stages?

Each stage tuned to its bottleneck: I/O tasks get 5-10× cores; CPU tasks get ~cores; GPU is orchestrated separately.

Worker Pool Pattern — System Design Concept

📚Worker Pool PatternPro

7 sections

~29 min total

30 quick quizzes

3 SD challenges linked

0 of 7 done·~30 min left

Concepts›Worker Pool Pattern›What is a Worker Pool?

0 / 7

7 sections~29 min

What is a Worker Pool?

Fixed set of workers pulling tasks from a queue, processing them, and acknowledging completion

ReadQuiz

~5 min

⋯

The Infinite Loop: Dequeue → Process → ACK/NACK

Each worker loops continuously pulling tasks, executing work, and confirming success or failure

ReadQuizCode

~5 min

⋯

Sizing Workers: CPU-bound vs I/O-bound vs DB-bound

Worker count depends on task type: cores for CPU, cores × wait ratio for I/O, tuned for DB

ReadQuizCode

~5 min

⋯

Graceful Shutdown: SIGTERM Handling and Draining In-Progress Jobs

Stop accepting tasks, complete in-flight work, ACK/NACK, close resources, then exit cleanly

ReadQuizCode

~5 min

⋯

System Design Question: Notification System

Multi-channel notification delivery using worker pools for push, email, and SMS with priorities

ReadQuizCode

~5 min

⋯

System Design Question: Children's Animation App

Multi-stage video processing pipeline with varying CPU/GPU/I/O workloads across serialized stages

ReadQuiz

~5 min

⋯

Practice test

30 questions

~10 min

🔒

Pro content

Worker Pool Pattern is a Pro concept. Upgrade to access full content, practice questions, and design challenges.

Upgrade to Pro →

Notes

🔍

Loading…