Ревью архитектуры ETL-приложения

Есть монолитное ETL-приложение на Python, которое извлекает данные из нескольких источников в БД, а после формирует из них CSV разного формата. Приложение разбито разве что на функции - в остальном это сплошной скрипт без классов и т.п.

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

Микросервисами это бы не назвал - цели развертывания более чем 1 экземпляра нет, БД одна, и самих частей приложения особо больше не должно появиться.

Скорее подойдет модули - со следующими задачами:

• API Gateway: принимает запросы от пользователей (в перспективе и фронтенда), ставит задачу и дает возможность получать её статус
• Оркестратор: управляет процессом выполнения задачи через вызов своих "подчиненных", обеспечивает консистентность процесса (порядок вызова, выполнение только одной задачи в момент времени)
• Extract-контейнеры: контейнеры под свой источник, чья задача 1-к-1 перенести данные в БД
• Load-контейнеры: контейнеры под свой формат выгрузки, чья задача "распилить", трансформировать и выгрузить данные на FTP
• Системные сервисы: для удобного администрирования БД и FTP через API (сейчас вручную) - также контролируется
• RabbitMQ: шина для взаимодействия модулей - постановка задачи и отчет о её выполнении
• Redis: хранилище данных о задачах (id, время создания, параметры создания, статус выполнения)

Хотелось бы услышать мнение со стороны - какие есть возможные недостатки или излишки у данной архитектуры?