🐘 Kafka реально быстрая, но я возьму Postgres

Перевели довольно длинный, но приземлённый разбор: зачем большинству проектов вообще тащить Kafka и пять разных баз, если тот же Postgres спокойно закрывает типичные нагрузки. Автор не просто рассуждает — он гоняет бенчмарки и смотрит, насколько далеко можно уехать на одном Postgres в сценариях pub/sub и очередей.

Если коротко, то по мир можно поделить на два лагеря:

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

🟣 Второй — те, кто начинают с базовых вещей и считают не только RPS, но и организационные издержки: новые системы надо изучать, мониторить, обновлять, поддерживать, и это обходится дороже, чем кажется. На этом фоне логика «просто используйте Postgres, пока не упрётесь в реальные лимиты» выглядит вполне рационально.

В бенчмарках Postgres выступает как и pub/sub, и очередь: десятки тысяч сообщений в секунду, мегабайты входящего/исходящего трафика, на относительно скромных инстансах и без экзотического тюнинга. Да, Kafka и спецочереди по-прежнему лучше оптимизированы под свои задачи и выигрывают на очень больших масштабах. Но до этих масштабов большинство систем просто не доходит — и в подавляющем числе кейсов упираться будете не в базу, а в продукт, команду или деньги.

Вместо «архитектуры как у Google» лучше думать в терминах минимально жизнеспособной инфраструктуры: взять Postgres и использовать его максимально просто и добавлять новые технологии только тогда, когда они реально нужны. Чем меньше компонентов — тем меньше точек отказа и меньше клейкого кода между ними.

Краткий вывод от статьи такой: начните с Postgres, держите стек простым, а к Kafka и прочим тяжёлым системам приходите только тогда, когда у вас действительно появятся проблемы их масштаба. Всё остальное — из серии «преждевременная оптимизация».

@go_for_devs