Главной проблемой, которую мы решали, было то, что у нас было легаси, которое было тяжело контролировать, а время ответа ручки не удовлетворяло требованиям к событийной системе.
Чем интересна данная тема для обсуждения? Это будет поверхностный обзор архитектуры событийных систем, с открытым для предложений окном.
Модный и популярный сейчас среди Go разработчиков протокол gRPC основан на Protobuf, который существует в нескольких версиях, сложность с Protobuf на Python в том, что Python 3 асинхронный лишь условно, а декодирование Protobuf блокирует другие операции системы так как по интерпретатор ограничен одним процессом.
Сложность такой системы в том, что когда система получает событие из запроса, она не отдаёт ответы и не принимает другие запросы, пока декодирует событие из запроса, но мы нашли архитектурное решение для этой проблемы.
Ручки сервиса будут просто проксировать приходящие Protobuf события так как они пришли в kafka, после чего отдельное приложение будет вычитывать сообщения и обрабатывать события.
