Масштабная событийка на практике: пайплайны, ретраи, DLQ и неочевидные сложности

Событийная архитектура кажется простой: «прочитал → обработал → закоммитил». На пилоте всё летает, переполнений «не было», стажёр справится за неделю. Но как только мы идём в массовое внедрение — десятки команд, тысячи сервисов — всплывают совсем другие задачи: пропускная способность, параметризация, наблюдаемость, гарантии, бесконечные ретраи, poisoned messages. В докладе я разберу три подхода к масштабированию событийки — от «каждый пишет сам» и «масштабируем лучшую библиотеку» до инверсии с push-моделью и общей «коммуналкой» — и покажу, как выглядит рабочее решение: прокси/пайплайны, коммунальные retry-queue, DLQ, circuit breaker-ы. Поделюсь метриками и граблями, а в конце сравню Kafka и Redpanda и дам ориентиры, что выбирать с учётом размера команды и бюджета на инфраструктуру.