System Design - lesson 5 | HackIndia Skills

Key point

Remember this

A queue lets your API accept work now and finish it later. The user gets a fast response, while a worker handles the slow or unreliable task in the background.

When to use it

Use a queue when work takes longer than a normal request should, or when an external service can fail. Common hackathon examples are sending OTP emails, generating PDFs, resizing images, calling an AI model, syncing UPI payment status, or sending WhatsApp alerts.

Do not put everything in a queue. Reading a profile, creating a simple record, or checking login should usually stay in the API request.

Your to-do

Basic flow

Do each one yourself, then tap it to tick it off. The ticks are only a checklist for you: they are not marked or scored.

Receive the client request in your API.
Save the main record in the database, such as order or submission.
Add a small job to the queue with an id, not a huge payload.
Return a quick response to the client, like 202 Accepted or status: queued.
Run a worker process that takes jobs from the queue and updates the database.

0 of 5 done

Example

Node queue example

This uses BullMQ with Redis. Redis is the broker here. Your API adds the job. A separate worker file processes it.

Install with npm install bullmq ioredis. Run Redis locally with Docker if you already use Docker.

// queue.js
const { Queue } = require('bullmq');

const connection = { host: '127.0.0.1', port: 6379 };

const emailQueue = new Queue('email', {
  connection,
  defaultJobOptions: {
    attempts: 3,
    backoff: { type: 'exponential', delay: 5000 },
    removeOnComplete: true,
    removeOnFail: false
  }
});

module.exports = { emailQueue };

// api.js
const express = require('express');
const { emailQueue } = require('./queue');
const app = express();
app.use(express.json());

app.post('/orders', async (req, res) => {
  const orderId = 'ord_' + Date.now();

  // Save order to DB here first
  await emailQueue.add('send-order-confirmation', {
    orderId,
    email: req.body.email
  });

  res.status(202).json({ orderId, status: 'queued' });
});

app.listen(3000);

// worker.js
const { Worker } = require('bullmq');

const connection = { host: '127.0.0.1', port: 6379 };

new Worker('email', async (job) => {
  console.log('Sending email for', job.data.orderId);
  // Call email provider here
  // Update order notification_status in DB
}, { connection });

Common mistake

Avoid this mistake

Do not treat a queued job as definitely done. It may fail, retry, or run later when the worker restarts.

Show job status in your app if the result matters. For example: queued, processing, completed, failed. Store that status in your database, not only in logs.

Tip

Keep jobs small

Put ids in the job payload, not full files or large JSON. The worker can fetch the latest data from the database using the id.

This makes retries safer. It also avoids old data being processed after the user has changed something.

What to document

In your HackIndia submission, add one small section called Queue choice. Say what work is queued, why it is slow, what broker you use, and what retry rule you picked.

Also write one trade-off. Example: The user gets a faster response, but the result is not immediate, so we show a status page and retry failed jobs three times.