В своей реализации я запускаю FastStream в качестве потребителя событий из брокера отдельным процессом. При этом кодовая база остается одной и той же. Меняется только точка входа в приложение. То есть у вас получается монолит только процесса обработки два - один для веб запросов, другой для потребителя ивентов. Можете назвать это "монорепо" если монолит режет слух из за нескольких запущенных процессов, главная суть в том что кодовая база остается единой. Если вы пишете синхронное Python приложение то FastStream поддерживает синхронную обработку сообщений. Если мне не изменяет память то процесс обработки там происходит почти так как вы описали, только потоки создаются на вызов а не хендлер, и складываются в общий пул после обработки, откуда потом берутся и переиспользуются для следующих запросов.
При этом если использовать паттерн Outbox вы должны запустить цикл поллера который будет дергать сохраненные события из бд и пересылать в брокер. Можно запускать его отдельным процессом, а можно и потоком внутри одного из процессов приложения, тут уж сами решайте.
В этой статье речь не о производительности, а о структурировании приложения. Ну и да, конечно, не один монолит не сравнится с микросервисами в долгосрочной перспективе, при росте нагрузки вам все равно придется разносить ваш монолит на отдельные сервисы каким бы он не был. Модульность, которую я описал в статье позволяет как раз таки заложить фундамент под этот будущий вынос.
То как реализовать dependency-injection сильно зависит от используемого веб фреймворка и от требований самого проекта. Поэтому подробно здесь не расписывал, как именно это нужно делать, но дал наводки на то, как можно, в зависимости от архитектуры.
В своей реализации я запускаю FastStream в качестве потребителя событий из брокера отдельным процессом. При этом кодовая база остается одной и той же. Меняется только точка входа в приложение. То есть у вас получается монолит только процесса обработки два - один для веб запросов, другой для потребителя ивентов. Можете назвать это "монорепо" если монолит режет слух из за нескольких запущенных процессов, главная суть в том что кодовая база остается единой. Если вы пишете синхронное Python приложение то FastStream поддерживает синхронную обработку сообщений. Если мне не изменяет память то процесс обработки там происходит почти так как вы описали, только потоки создаются на вызов а не хендлер, и складываются в общий пул после обработки, откуда потом берутся и переиспользуются для следующих запросов.
При этом если использовать паттерн Outbox вы должны запустить цикл поллера который будет дергать сохраненные события из бд и пересылать в брокер. Можно запускать его отдельным процессом, а можно и потоком внутри одного из процессов приложения, тут уж сами решайте.
В этой статье речь не о производительности, а о структурировании приложения. Ну и да, конечно, не один монолит не сравнится с микросервисами в долгосрочной перспективе, при росте нагрузки вам все равно придется разносить ваш монолит на отдельные сервисы каким бы он не был. Модульность, которую я описал в статье позволяет как раз таки заложить фундамент под этот будущий вынос.
То как реализовать dependency-injection сильно зависит от используемого веб фреймворка и от требований самого проекта. Поэтому подробно здесь не расписывал, как именно это нужно делать, но дал наводки на то, как можно, в зависимости от архитектуры.