Redis Streams vs очереди PostgreSQL для рабочей архитектуры

Почему этот выбор позже становится дорогим

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

Ваша основа рабочих процессов решает не только то, где ждут задачи. Она влияет на повторные попытки, обработку сбоев и восстановление после неудачного деплоя или простоя. Когда эта модель неясна, команды начинают латать ее поверх. В одном сервисе появляется флаг retry, в другом — таймаут, а потом кто-то вручную запускает SQL-скрипт, потому что ничего другого не помогает.

Именно поэтому «Redis Streams vs PostgreSQL queues» — это не простой тест на скорость. Вы выбираете правила работы. Насколько строгим должен быть порядок? Как долго сообщения должны храниться? Что считать завершением? Кто убирает хвосты, когда воркеры отстают?

Изменить курс позже дорого. Код, построенный вокруг строк в базе и транзакционных обновлений, не переходит аккуратно к модели потокового потребителя. Код, завязанный на groups потребителей и подтверждения, не переносится в SQL-очередь без переписывания повторных попыток, правил видимости и мониторинга. Потом начинается перенос данных. Исторические задачи, состояние повторных попыток и записи о сбоях все должны получить новое место, и команды часто слишком поздно понимают, что не сохраняли достаточно деталей для безопасного повторного запуска.

Именно на повторной обработке ломается много ранних решений. Сначала команда может сосредоточиться на пропускной способности и пропустить аудит, потому что система еще кажется маленькой. Через шесть месяцев поддержка задает простые вопросы: какие задачи запускались? Какие упали? Какие повторяли три раза? Можно ли запустить заново только сломанные? Если ответ — «возможно, через скрипт», затраты на поддержку начинают расти.

Мелкие решения быстро складываются в большую проблему. Одно слабое правило дедупликации может каждую неделю создавать дубликаты побочных эффектов. Слабый порядок может перемешать состояние аккаунта. Короткое хранение может стереть доказательства, которые нужны во время инцидента. В дизайне это выглядит не драматично. Но очень реально, когда один инженер каждое утро тратит 20 минут на проверку зависших задач и их очистку.

Что дает каждый вариант

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

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

Очереди PostgreSQL начинаются с таблицы задач. Продюсер вставляет строку, а воркеры забирают строки и по ходу меняют состояние. Большинство команд добавляют поля вроде status, attempts, available_at, locked_by, locked_at и last_error. Очередь — это не отдельная система. Это обычные данные приложения с SQL вокруг них.

Это различие важно каждый день. В PostgreSQL повторные попытки обычно означают обновить ту же строку и сдвинуть время следующего запуска вперед. В Redis Streams повторные попытки часто означают, что та же запись потока остается в pending, пока воркер не подтвердит ее или пока другой воркер не заберет ее. Обе модели умеют повторять работу, но фиксируют ее по-разному.

Очистка идет тоже разными путями. Redis Streams хранит данные, пока вы не обрежете их по длине или возрасту. Забыли об этом — и память растет. Обрезали слишком агрессивно — и возможности повторной обработки исчезают. Очередям PostgreSQL нужны удаления, архивирование или партиционирование. Оставьте все старые задачи в одной загруженной таблице — и запросы замедлятся, а объем работы vacuum вырастет.

Для многих команд PostgreSQL кажется проще, потому что данные видимы и привычны. Вы можете смотреть строки, связывать их с бизнес-записями и проверять изменения обычным SQL. Redis Streams часто кажется легче и быстрее для большого потока событий, но добавляет отдельную модель эксплуатации. В этом и есть настоящий компромисс: семантика журнала событий против семантики состояния строк.

Порядок при реальной нагрузке

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

Очередь может хранить задачи в понятной последовательности. Это не значит, что воркеры завершат их в том же порядке. Воркер A может взять задачу 101, воркер B — 102, а 102 завершится раньше, потому что она меньше или потому что 101 ждет медленный API.

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

Что обычно значит «по порядку»

Когда вы используете разделы, шарды или группы потребителей, порядок обычно означает «внутри одной линии», а не «во всей системе». Этого часто достаточно, если правильно определить саму линию.

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

Очереди PostgreSQL и Redis Streams оба упираются в это ограничение. В PostgreSQL воркеры, которые одновременно опрашивают базу, могут спорить друг с другом. В Redis группы потребителей тоже распределяют сообщения между потребителями, и медленный потребитель может отстать, пока остальные продолжают движение.

Как транзакции меняют картину

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

У PostgreSQL здесь явное преимущество. Вы можете записать бизнес-данные и добавить запись очереди в одной транзакции. Это связывает изменения состояния и очередь работы между собой.

С Redis командам часто нужна outbox-таблица или другой шаг восстановления, чтобы получить такую же безопасность. Это не стоп-фактор, но это добавляет работы оператору и еще одно место, где могут спрятаться ошибки порядка.

Если порядок важен, сначала определите единицу. Решите, важен ли порядок на уровне клиента, аккаунта, документа или всего запуска процесса. Обычно это важнее, чем название очереди.

Повторная обработка, обратная загрузка и аудит

Повторная обработка становится важной в тот момент, когда ошибка отправляет 4000 задач не туда, куда нужно, или когда после изменения правил приходится заново обработать записи за прошлый месяц. Команды часто думают сначала о пропускной способности, а о повторной обработке — потом. Такой порядок делает все дороже.

С Redis Streams повторная обработка работает только если события еще существуют. Это звучит очевидно, но многие команды обрезают потоки, чтобы экономить память. Если вы храните только последние 100 000 записей и обнаруживаете ошибку через три дня, более старые события могут уже исчезнуть. Группы потребителей помогают отследить, что прочитал каждый воркер, но они не заменяют долгосрочную историю.

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

Повторная обработка в PostgreSQL обычно начинается с сохраненных строк. Типичная схема хранит каждую задачу или событие в таблице с полями вроде status, attempts, created_at, processed_at и error_message. Когда ошибка исправлена, команда может сбросить группу строк из failed в pending или создать свежую партию из тех же исходных записей. Это медленнее, чем чтение из памяти, но рассуждать об этом намного проще.

Простой пример показывает разницу. Представьте поток регистрации в SaaS, где каждому новому клиенту отправляется приветственное письмо, начисляются пробные кредиты и создается запись в CRM. Если правило начисления было неверным две недели, очередь PostgreSQL обычно позволяет найти такие строки запросом и повторно выполнить только этот шаг. В Redis это можно сделать только если исходные события сохранились или если вы где-то еще держали их надежную копию.

Аудит часто подталкивает команды к PostgreSQL. В конце концов люди начинают задавать очень прямые вопросы: что произошло с клиентом 1824? Какой воркер выполнил эту задачу? Когда она упала и сколько раз? Какая версия правила дала такой результат?

Таблица очереди или таблица событий делает такие ответы проще для хранения и поиска. Речь не только о скорости. Речь еще и об истории. Если ваш процесс влияет на биллинг, согласования, комплаенс или данные клиентов, долговечные строки обычно лучше быстрых временных сообщений.

С чем операторы сталкиваются каждую неделю

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

Redis Streams заставляет внимательно следить за памятью. Старые записи не исчезают сами, поэтому кому-то нужны правила обрезки, лимиты хранения и проверки резкого роста после замедления воркеров. PostgreSQL переносит боль на диск: таблицы растут, индексы раздуваются, autovacuum отстает, а задачам очистки нужно постоянное внимание.

Бэкапы и восстановление тоже различаются на практике. Если задачи все еще важны после перезапуска, PostgreSQL обычно проще объяснить, потому что очередь живет рядом с остальными данными приложения, с тем же потоком бэкапов и теми же учениями по восстановлению. Redis тоже умеет сохранять данные потока, но команды часто узнают, что хранить сообщения — это не то же самое, что восстановить чистое состояние потребителей после failover.

Медленные воркеры создают работу и там, и там, просто в разных местах. В Redis неподтвержденные записи копятся в группах потребителей, начинают иметь значение таймеры простоя, и один плохой деплой может вызвать лавину повторных попыток. В PostgreSQL зависшие задачи обычно видны как строки, которые так и не ушли из статуса «running», как аренды, которые истекают слишком поздно, или как воркеры, которые снова и снова берут один и тот же неудачный элемент.

Небольшой еженедельный чек-лист помогает лучше, чем красивая схема. Проверьте рост очереди относительно политики хранения. Посмотрите на количество повторных попыток и объем неудавшихся задач. Найдите потребителей или воркеры, которые перестали двигаться. Один раз протестируйте путь восстановления для задач, которые все еще важны. Проверьте поведение при отказе под нагрузкой, а не только в staging.

Правила failover сильнее влияют на нагрузку дежурных, чем думают многие команды. Redis с репликами, Sentinel или cluster mode требует четких правил для promotion, переподключений и владения сообщениями после смены узла. У PostgreSQL есть свои острые углы, но многие команды уже умеют с ним работать, так что добавление очереди туда может означать меньше движущихся частей.

Часто именно в этом и состоит еженедельный компромисс. Если команда уже хорошо работает с PostgreSQL, а очередь находится близко к основным данным, PostgreSQL обычно дает меньше сюрпризов. Если вам нужен большой поток событий и короткоживущая работа, Redis может подойти, но только если кто-то дисциплинированно отвечает за лимиты памяти, восстановление потребителей и очистку.

Именно поэтому опытные CTO советуют оценивать время команды, а не только скорость в бенчмарке. Более быстрая очередь все равно может стоить дороже, если будит людей в 2:00 ночи.

Простой пример из потока регистрации в SaaS

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

Одна регистрация может вызвать четыре действия: отправить приветственное письмо, создать или обновить платежную запись, добавить нового клиента в CRM и отправить webhook в другое приложение.

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

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

Redis Streams лучше подходит, когда вам важнее быстро раздать событие нескольким потребителям и иметь возможность повторной обработки. Если синхронизация с CRM отстала на 20 минут или endpoint партнера упал, поддержка может позже повторно проиграть пропущенные webhook-события. Это реальное преимущество, когда внешние системы ломаются, а это происходит часто.

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

Большинству команд не нужна одна идеальная основа для всего. Им нужна наименее рискованная модель для той ошибки, которая причинит больше всего боли. Если двойное списание станет катастрофой, выбирайте модель, которая делает биллинг строгим и простым для проверки. Если пропущенные downstream-события создают больший хаос, выбирайте модель, где повторная обработка дешевле и привычнее.

Как выбирать шаг за шагом

Начните с работы, а не с базы данных. Команды часто берут Redis, потому что он похож на очередь, или PostgreSQL, потому что они и так его используют. Такой shortcut становится дорогим, когда вам нужна повторная обработка, аудит или спокойные ночные дежурства.

Лучше работает простой процесс выбора, а не абстрактный спор. Выпишите все задачи, которые делает ваше приложение, и отметьте каждую как «строгий порядок» или «порядок не слишком важен». Событие биллинга и приостановка аккаунта часто требуют ясной последовательности. Приветственное письмо обычно не требует.

Затем решите, как долго история задач должна оставаться полезной. Если вам может понадобиться повторно запустить работу на следующей неделе, восстановить состояние после бага или ответить на вопрос «что случилось с этим клиентом?» через три месяца, заложите это в проект с самого начала.

Дальше перечислите сбои, которые ваша команда уже видит: дублирующиеся webhook, воркеры, которые падают посреди задачи, медленные API третьих сторон и деплои, оставляющие незавершенную работу позади. Правильная модель очереди должна делать эти сбои скучными.

После этого назовите человека, который будет отвечать за бэкапы, очистку, обработку неудавшихся задач и оповещения. Это звучит скучно, но часто именно это и решает исход. Если ваша команда уже хорошо знает PostgreSQL и не хочет еще один сервис, это важно. Если вы уже аккуратно работаете с Redis и вам нужен очень быстрый fan out, это тоже важно.

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

Вот тогда выбор становится практическим. Выберите модель, которая подходит вашим правилам порядка, вашему окну повторной обработки и людям, которым придется поддерживать ее в 2:00 ночи. Короткий пилот обычно решает спор быстрее, чем еще одно архитектурное совещание.

Ошибки, которые команды делают в начале

Команды часто выбирают очередь после одного быстрого бенчмарка и считают проблему решенной. Так маленькие тестовые результаты превращаются в долгий еженедельный налог. Поток, который в лаборатории выглядит дешевым на 10 000 сообщений, может стоить гораздо дороже, когда люди начинают разбираться с зависшими задачами, повторно проигрывать пропущенную работу, обрезать старые данные и отвечать на вопросы вроде «эта задача запускалась дважды?».

Еще одна частая ошибка — считать журнал событий и очередь задач одним и тем же. Они связаны, но решают разные задачи. Очередь задач отвечает на вопрос «что воркер должен сделать дальше?». Журнал событий отвечает на вопрос «что произошло, в каком порядке и можем ли мы прочитать это позже снова?». Redis Streams находится где-то посередине, и это полезно, но им легко неправильно пользоваться. PostgreSQL тоже может закрывать оба сценария, но только если вы аккуратно спроектируете таблицы, повторные попытки и правила хранения.

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

Очистку хранилища тоже слишком долго игнорируют. Потом однажды очередь оказывается огромной, старые задачи все еще лежат там, и никто не может договориться, что должно остаться. Если вы используете Redis Streams, вам нужна четкая политика обрезки и правило для pending-записей, которые воркеры так и не подтвердили. Если вы используете PostgreSQL, вам нужен план для старых строк, индексов, давления vacuum и срока жизни данных для повторной обработки.

Многие команды еще и копируют выбор компании с совсем другой нагрузкой. Такой shortcut причиняет больше боли, чем ожидают люди. Продукт с короткими, одноразовыми фоновыми задачами может нормально жить с одной моделью. Система, которой нужны повторная обработка, аудит и длинные процессы, может потребовать другой.

Лучший ранний чек простой. Запишите, что должно сохранять порядок на уровне пользователя, аккаунта или глобально. Решите, как вы будете повторно запускать работу после исправления бага. Задайте правила хранения и очистки до запуска. Считайте время команды, а не только пропускную способность сообщений. Тестируйте сбои, а не только нормальную скорость.

Обычно именно здесь спор перестает быть о бенчмарках и начинает выглядеть как операционное решение.

Быстрые проверки перед выбором

Большинству команд хватает десяти минут, чтобы сузить выбор, если они ответят на несколько прямых вопросов. Лучшая архитектура на бумаге часто проигрывает той, которую ваша команда может спокойно поддерживать в загруженную неделю и отлаживать полусонной.

Если ваша работа похожа на обычную job queue, PostgreSQL часто выигрывает тем, что он скучный и простой в поддержке. Если одним и тем же потоком событий должны пользоваться многие потребители, Redis Streams начинает выглядеть логичнее, потому что он создавался для fan out, групп потребителей и окон повторной обработки.

Несколько проверок помогают. Если один воркер должен забрать задачу, выполнить ее и отметить завершенной, PostgreSQL обычно достаточно. Если несколько сервисов должны независимо читать один и тот же поток событий, Redis Streams подходит лучше. Если старые задачи могут исчезать через несколько дней, политики хранения Redis могут быть нормальными. Если вам нужен более длинный журнал, PostgreSQL проще сохранять и проверять. Если ваша команда и так каждый день живет в Postgres, то одна база может сократить объем поддержки, бэкапов и дежурств.

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

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

Отладка — последний чек, и он действительно важен. В 2:00 ночи сможет ли кто-то из вашей команды быстро ответить на три вопроса: что было поставлено в очередь, кто это забрал и что произошло дальше? В PostgreSQL это часто означает несколько SQL-запросов к таблицам, которые вы уже знаете. В Redis Streams ответы тоже есть, но команде нужно уверенно работать со stream ID, pending-записями, подтверждениями и правилами хранения.

Для многих небольших SaaS-команд достаточно самого простого ответа: начните с Postgres, если вам нужна надежная job queue и более простая поддержка. Выбирайте Redis Streams, когда вам действительно нужен поток событий с несколькими читателями, повторная обработка и больше контроля над поведением потребителей.

Что делать дальше

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

Эта заметка быстро вскрывает слабые предположения. Команды часто говорят, что им нужен строгий порядок, а потом понимают, что порядок нужен только на уровне пользователя или аккаунта. Они также говорят, что повторная обработка важна, но только для нескольких процессов, например исправлений биллинга, импорта данных или отложенных webhook.

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

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

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

Если это решение может повлиять на расходы в облаке, время сотрудников или uptime, короткий архитектурный разбор обычно того стоит. Oleg Sotnikov на oleg.is работает со стартапами и небольшими командами над такими решениями как Fractional CTO и advisor, особенно когда проектирование workflow, инфраструктура и AI-driven разработка начинают пересекаться.

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