Подсистема хранения для Event sourcing

Основные требования:

  1. Постоянное надежное хранение
  2. Определен порядок событий
  3. Обычно не нужно изменять/удалять, но иногда нужно. 2 примера:
    1. Клиент отключился. Мы не хотим хранить его данные для уменьшения стоимости хранения и по юридическим требованиям.
    2. У нас SaaS решение и в тарифе есть ограничение на историю хранения (для ограничения стоимости на хранение) – нужно удалять

Отдельный вопрос хотим ли мы менять старые события, чтобы мигрировать их к новой схеме событий: один вариант приводить (но есть вероятность что-то испортить), второй не приводить и вечно поддерживать все версии всех событий в коде (удорожание поддержки).

Глобально 4 решения:

  1. традиционная БД (например PostgreSQL)
  2. документоориентированная БД (например MongoDB)
  3. система очередей (например Kafka)
  4. специализировання система (например https://www.eventstore.com/ или https://developer.axoniq.io/axon-server/overview)

В целом, после размышлений, у меня примерно такие выводы:

  1. Не видел хороших специализированных open source решений (уровня PostgreSQL), а использовать коммерческие как основу для продукта все-таки плохо (не зря последние годы многие даже не рассматривают тот же Oracle)
  2. С очередями дополнительные проблемы (т.к. они более ограничены, чем БД), но начиная с какого-то масштаба имеет смысл
  3. документоориентированная БД или традиционная – не так принципиально, это скорее про используемые в компании технологии