Что такое очередь

Очередь отвечает на простой вопрос: кто должен быть обработан следующим. Если элемент пришел раньше других, он будет обслужен раньше. Поэтому очередь часто сравнивают с живой очередью в магазине.

Минимальный контракт такой:

• enqueue добавляет элемент в конец;
• dequeue забирает элемент из начала;
• peek смотрит первый элемент без удаления;
• isEmpty проверяет, есть ли элементы.

На интервью можно начать именно с этого. Потом добавьте практический смысл: очередь нужна там, где порядок важнее случайной скорости обработки.

Для короткого ответа можно показать простую реализацию через массив. Но сразу назовите ее ограничение. Так вы не звучите так, будто это всегда production-решение.

class Queue {
  constructor() {
    this.items = [];
  }

  enqueue(item) {
    this.items.push(item);
  }

  dequeue() {
    return this.items.shift();
  }

  peek() {
    return this.items[0];
  }

  isEmpty() {
    return this.items.length === 0;
  }
}

const queue = new Queue();
queue.enqueue("save draft");
queue.enqueue("send analytics");

console.log(queue.dequeue()); // "save draft"

Это хороший учебный пример. Риск в том, что shift удаляет первый элемент, после чего массиву может понадобиться переиндексация. На маленьких данных это не проблема. Для большого потока задач лучше выбрать реализацию с индексом головы.

Разделяйте две вещи: поведение очереди и способ хранения данных. Поведение одно: FIFO. Хранение может быть разным.

Если задача учебная, массив читается проще. Если очередь живет долго, часто меняется и может расти, лучше не делать решение, которое постоянно двигает элементы внутри массива. Если очередь управляет запросами, одной структуры данных мало: нужен код, который запускает задачи, ловит ошибки и не ломает UI.

Во фронтенде очередь полезна не потому, что вам нужно каждый день писать структуры данных вручную. Она помогает объяснить порядок выполнения и защититься от хаоса в UI.

Примеры:

• показывать toast-уведомления по одному, а не все сразу;
• отправлять изменения формы по порядку и проверять актуальность ответа, чтобы старый запрос не перезаписал новый результат;
• ограничивать число параллельных загрузок файлов, чтобы не забить сеть и не сломать прогресс в UI;
• обрабатывать пользовательские действия, которые нельзя потерять;
• строить retry-механизм для временно неудачных задач.

Практический риск такой: если вы называете все это очередью, но запускаете задачи одновременно без контроля, порядок обработки уже не гарантирован. В интерфейсе это часто выглядит как лишние запросы, мигающий loading, неправильный порядок уведомлений или перезапись свежих данных старым ответом.

Плохой пример: сложить функции в массив и запустить обработчик без обработки ошибок.

const queue = [];
let running = false;

async function processQueue() {
  if (running) return;
  running = true;

  while (queue.length > 0) {
    const task = queue.shift();
    await task();
  }

  running = false;
}

Если task() выбросит ошибку, флаг running может остаться в состоянии true, а очередь перестанет обрабатываться. Для пользователя это может выглядеть как вечный loading, потерянное действие или уведомление, которое так и не появилось. Безопаснее использовать try/finally для состояния обработчика и try/catch для отдельной задачи.

const queue = [];
let running = false;

function enqueue(task) {
  queue.push(task);
  void processQueue();
}

async function processQueue() {
  if (running) return;
  running = true;

  try {
    while (queue.length > 0) {
      const task = queue.shift();

      try {
        await task();
      } catch (error) {
        console.error("Queue task failed", error);
      }
    }
  } finally {
    running = false;
  }
}

Это все еще простой пример, не идеальная библиотека очередей. Но он показывает важную мысль для интервью: очередь задает порядок, а надежность обработки нужно проектировать отдельно. Если задачи делают сетевые запросы из React-компонента, отдельно продумайте отмену через AbortController или игнорирование устаревшего результата после размонтирования. Иначе можно получить лишний запрос или обновить уже неактуальное состояние.

Очередь не равна массиву. Массив может быть основой реализации, но если вы делаете push и pop, у вас получается стек, потому что удаляется последний добавленный элемент.

Очередь не равна Event Loop. В браузере действительно есть очереди задач и микрозадач, но это отдельная тема про runtime. В ответе на базовый вопрос лучше не уходить глубоко в Event Loop, если вас не попросили. Скажите, что идея FIFO используется в планировании задач, а затем вернитесь к контракту структуры данных.

Очередь не гарантирует порядок завершения сетевых запросов. Если вы достали из очереди две задачи и запустили их параллельно, ответ второй задачи может прийти раньше. Для UI это может привести к race condition, когда старые данные перезаписывают новые.

Хороший ответ на интервью может быть коротким и прикладным:

Очередь это структура данных с FIFO-порядком. Мы добавляем элементы в конец, а извлекаем из начала, поэтому первый пришедший элемент обрабатывается первым. Во фронтенде это полезно для задач, где важен порядок: уведомления, пользовательские действия, фоновые запросы. Для простого примера можно использовать массив, но в реальном коде нужно учитывать цену shift, ошибки async-задач и возможную параллельность.

Такой ответ показывает определение, операции, отличие от стека и практический риск. Этого обычно достаточно, чтобы дальше спокойно отвечать на уточняющие вопросы.