How would you implement a distributed task queue in Go without using an external framework?

Q: How would you implement a distributed task queue in Go without using an external framework?

type Task struct { ID string `json:"id"` Type string `json:"type"` Payload json.RawMessage `json:"payload"` } type Queue struct { rdb *redis.Client key string dlqKey string // dead letter queue } func (q *Queue) Enqueue(ctx context.Context, task Task) error { data, err := json.Marshal(task) if err != nil { return err } return q.rdb.RPush(ctx, q.key, data).Err() } func (q *Queue) Dequeue(ctx context.Context, timeout time.Duration) (*Task, error) { // BLPOP blocks until item available or timeout result, err := q.rdb.BLPop(ctx, timeout, q.key).Result() if err == redis.Nil { return nil, nil } // timeout, no item if err != nil { return nil, err } var task Task if err := json.Unmarshal([]byte(result[1]), &task); err != nil { return nil, err } return &task, nil } func (q *Queue) Worker(ctx context.Context, handler func(context.Context, Task) error) { for { task, err := q.Dequeue(ctx, 5*time.Second) if err != nil { log.Printf("dequeue error: %v", err); continue } if task == nil { // timeout if ctx.Err() != nil { return } // context cancelled continue } if err := handler(ctx, *task); err != nil { log.Printf("task %s failed: %v", task.ID, err) // Send to DLQ q.rdb.RPush(ctx, q.dlqKey, task) } } } At-least-once delivery: use RPOPLPUSH to move task to processing list, remove after success Idempotency: store processed task IDs in DB with a UNIQUE constraint to handle duplicate delivery asynq library: production-grade Redis-based queue with retries, scheduling, and dashboard Kafka with segmentio/kafka-go: durable, ordered, replayable — prefer over Redis for high-volume event streams Dead letter queue: capture failed tasks for manual inspection and replay after bug fixes

Difficulty: 8/10

worker coordination, persistence, fault tolerance

Use Redis lists (BLPOP/RPUSH) or Kafka topics as the queue, goroutines as workers, and implement heartbeat/lease mechanisms for at-least-once delivery with a dead letter queue for failures.

Redis-based task queue

Production considerations

1
At-least-once delivery: use RPOPLPUSH to move task to processing list, remove after success
2
Idempotency: store processed task IDs in DB with a UNIQUE constraint to handle duplicate delivery
3
asynq library: production-grade Redis-based queue with retries, scheduling, and dashboard
4
Kafka with segmentio/kafka-go: durable, ordered, replayable — prefer over Redis for high-volume event streams
5
Dead letter queue: capture failed tasks for manual inspection and replay after bug fixes

Scenario Questions

0-2 years experience

1Suppose you need to process image‑resizing jobs in a Go service. How would you set up a simple in‑memory task queue that workers can pull from without using any external libraries?
2If a worker crashes while processing a job, what happens to the task in your in‑memory queue, and how could you detect and retry it?
3How would you ensure that multiple goroutine workers don’t pick the same job from the queue?

2-5 years experience

1You’re adding a background email‑sending feature to an existing Go microservice. Describe how you would design a distributed task queue that works across multiple instances, handling persistence and retries, without pulling in a library like NSQ.
2During load testing you notice tasks sometimes get lost when a node restarts. What could be causing this, and how would you modify your queue implementation to fix it?
3Explain the trade‑offs between using a central Redis list versus a peer‑to‑peer gossip protocol for coordinating workers in your Go queue.

5-8 years experience

1Design a fault‑tolerant distributed task queue in Go that must handle millions of tasks per hour, guarantee at‑least‑once delivery, and survive network partitions. What components would you build, and how would they interact?
2How would you implement back‑pressure and rate limiting in your Go task queue to prevent overwhelming downstream services while still maintaining high throughput?
3If you need to add priority handling to your queue, what changes would you make to the data structures and worker logic, and what impact does it have on consistency and performance?

8+ years experience

1Your company is migrating from a legacy monolith that uses a custom task queue to a cloud‑native microservice architecture in Go. How would you plan the migration to ensure zero downtime and data integrity, and what long‑term design patterns would you adopt for the new queue?
2Across several teams you need a shared distributed task queue that supports pluggable persistence backends and observability. What high‑level architecture would you propose, and how would you govern its evolution to avoid lock‑in?
3Discuss how you would incorporate tracing, metrics, and automated failure injection into the Go task queue to meet SLOs for latency and reliability across a global deployment.

Follow-up Questions

What would you monitor to detect a stuck worker?
How would you handle task ordering guarantees?
Can you describe how you’d test the failure‑recovery path?