Мы строим систему источников событий в моей компании, опираясь на Kafka.
Чтобы быть совместимыми с GDPR, мы должны иметь возможность обновлять события.
Наша идея состоит в том,использовать возможности сжатия и захоронения.
Это означает, что мы не можем использовать стратегию разделения по умолчанию, так как мы хотим, чтобы каждое сообщение имело уникальный ключ (для перезаписи определенного сообщения), но нам все еще нужны событияпроисходит в том же агрегате и заканчивается в том же разделе.
Что приводит нас к созданию настраиваемого разделителя (в основном копирование логики "hash modulo" разделителя по умолчанию, но с использованием значения, отличного от сообщенияключ для вычисления хэша).
Проблема заключается в том, что мы развиваемся в среде полиглота (у нас есть службы публикации и использования php, python и Java / Kotlin и потребления событий).
Мы хотимчтобы все эти службы создавали сообщения для одного и того же раздела с заданным ключом раздела (в случае, еслиСлужбы будут публиковать события на одну и ту же тему).
Наша основная идея состояла в том, чтобы использовать общий алгоритм хеширования, но нам трудно найти его с надежной гарантией распространения и хорошей стабильностью (не только частьюэкспериментальная библиотека).
PHP изначально поддерживает широкий спектр алгоритмов хеширования , но нам трудно найти такую же поддержку в других языках.
Как и у Kafkaразделитель по умолчанию опирается на murmur2, мы также начали смотреть в этом направлении.К сожалению, он изначально не поддерживается php (хотя существуют реализации ).Кроме того, в этом алгоритме используется начальное число, что означает, что нам нужно будет использовать одно и то же начальное число для всех наших издательских услуг, что начинает делать подход достаточно сложным.
Однако мы могли бы рассмотретьдизайн под неправильным углом.Совместное использование возможностей записи в хранилище событий через сервисы полиглотов может быть не очень хорошей идеей, и у каждого сервиса может быть своя собственная логика секционирования, если она обеспечивает требование «один раздел на агрегат».Дело в том, что мы должны думать об этом заранее, потому что никакая техническая защита не помешает одной службе в будущем публиковать в «общем» потоке событий (и если не использовать точно такую же логику разделения, это будет иметь огромное влияние, когда это произойдет).
Кто-нибудь имел бы опыт создания магазина событий с Kafka в среде полиглота, и не могли бы вы выделить нас по этой конкретной теме, пожалуйста?