> С какими транспортными протоколами и технологиями вы работали (брокеры сообщений, вебсокеты, вебхуки) (JavaScript)

Короткий ответ

В production-проектах работал с WebSocket (через Socket.IO и ws), RabbitMQ (AMQP) и вебхуками (Express + signed payloads). WebSocket использовал для real-time дашбордов и чатов, RabbitMQ - для асинхронной обработки задач и event-driven архитектуры, вебхуки - для интеграций с внешними сервисами (платежи, CI/CD).

Подробное объяснение

WebSocket - полнодуплексный протокол поверх TCP, идеален для real-time коммуникаций. На Node.js чаще всего использую Socket.IO (с fallback на long-polling) или чистый ws для минимального оверхеда. Основные trade-off: поддержка состояния на сервере, масштабирование через Redis adapter, управление reconnection.

Брокеры сообщений (RabbitMQ) - для decoupling микросервисов и обработки фоновых задач. Использую amqplib с паттернами: direct exchange для routing по ключам, topic exchange для гибкой фильтрации, dead letter queues для обработки ошибок. Важно: подтверждения (ack/nack), prefetch count, TTL сообщений.

Вебхуки - HTTP callbacks, обычно POST с JSON payload. Ключевые моменты: верификация через HMAC-подпись (shared secret), идемпотентность (idempotency key), retry-логика с exponential backoff, очередь на случай недоступности получателя.

На практике

В одном проекте (real-time трейдинг) использовал WebSocket для стриминга цен - Socket.IO с Redis adapter для горизонтального масштабирования, сжатие сообщений через permessage-deflate. Для ордеров - RabbitMQ с подтверждениями, чтобы гарантировать доставку даже при падении воркера.

В другом проекте (платежный шлюз) - вебхуки от Stripe: верификация подписи через crypto.timingSafeEqual, обработка в очереди Bull (Redis), retry с задержкой. Для внутренних событий - RabbitMQ fanout exchange, чтобы несколько сервисов получали уведомления о статусе платежа.

Пример кода

JAVASCRIPT
// WebSocket (ws) + RabbitMQ consumer
const WebSocket = require('ws');
const amqp = require('amqplib');

async function start() {
  const connection = await amqp.connect('amqp://localhost');
  const channel = await connection.createChannel();
  await channel.assertQueue('orders', { durable: true });
  channel.prefetch(1);

  const wss = new WebSocket.Server({ port: 8080 });
  
  wss.on('connection', (ws) => {
    ws.on('message', (msg) => {
      channel.sendToQueue('orders', Buffer.from(msg), { persistent: true });
    });
  });

  channel.consume('orders', async (msg) => {
    try {
      const data = JSON.parse(msg.content.toString());
      // обработка заказа
      wss.clients.forEach(client => {
        if (client.readyState === WebSocket.OPEN) {
          client.send(JSON.stringify({ status: 'processed', id: data.id }));
        }
      });
      channel.ack(msg);
    } catch (err) {
      channel.nack(msg, false, true); // requeue
    }
  });
}

Как отвечать на собеседовании

Начни с перечисления конкретных технологий и сценариев их использования. Покажи понимание trade-off: когда WebSocket избыточен (лучше SSE или polling), когда брокер необходим (гарантированная доставка, backpressure). Упомяни edge cases: reconnection storm, backpressure в WebSocket, poison messages в очереди. Добавь про мониторинг (metrics через Prometheus) и отладку (Wireshark для WebSocket, RabbitMQ Management UI).

Что проверяет интервьюер

• Понимание различий между транспортными протоколами (TCP vs HTTP, pull vs push)
• Знание реальных проблем: потеря соединения, дубликаты, порядок сообщений
• Опыт с масштабированием (кластеризация WebSocket, clustering RabbitMQ)
• Навыки обработки ошибок и гарантий доставки (at-least-once, exactly-once)
• Умение выбирать инструмент под задачу (не использовать WebSocket для batch-задач)

Типичные ошибки

• Путать WebSocket и Socket.IO (первый - протокол, второй - библиотека с fallback)
• Игнорировать backpressure в WebSocket (сервер может захлебнуться при быстром клиенте)
• Не настраивать prefetch в RabbitMQ (все сообщения уходят одному потребителю)
• Доверять вебхукам без верификации (подпись обязательна)
• Использовать брокер там, где достаточно HTTP (overengineering)
• Забывать про graceful shutdown (закрывать соединения, ack оставшиеся сообщения)