Engineering Team Lead – Fiverr
  • Збираємо 31 млн грн на PD-2 — святкуємо 31 рік Незалежності України

  • Володимир Бондаренко, CEO Mauris, — чому відмовилися від аутсорсу і як розробляють ігри на Unity

    С нетерпением жду релиза игры.

  • Эволюция архитектуры проекта. Из монолита в микросервисы

    По поводу преимущества.

    Так как система хранит внутри себя историю всех изменений, то можно откатить её до любого момента времени. Например что-то пошло не так и неправильная обработка привела к проблемам с целостностью бд. В таком случаем можно её легко восстановить поменяв логику и обработав события заново. Без es в таком случае это может занять очень большой промежуток времени, если это вообще возможно.

    Следующий пример это возможность строить read модели со структурой как тебе удобно и в любой момент. Работа с аналитикой и системой для отчётов это отдельное удовольствие.

    Насчёт проблемы с асинхронными событиями.

    В твоем конкретном примере перед тем как послать событие с созданием товара как раз можно сделать все проверки на наличие. Или же можно разделить событие на несколько — юзер создал заказ, заказ проверен на все наличия и тд. Или же просто вернуть юзеру сообщение о том, что товара еще нет. Если read модель работает быстро, то таких случаев достаточно мало и иногда просто достаточно попробовать обработать их еще раз через какой-то retry период.

    В комментарии выше я описал примерные подходы для решения этой проблемы. Скорее это не недостаток es, а боль:), которую можно грамотно решить в зависимости от проблемы.

  • Эволюция архитектуры проекта. Из монолита в микросервисы

    Очень хороший вопрос. Ответ на него сильно зависит от самой задачи и есть несколько вариантов.

    Например для финансового сектора, где конечное состояние агрегата намного важнее скорости работы с ним, можно использовать мутексы и применять изменения только после того как все параллельные чтения с этим агрегатом были завершены. Так как lock применяется конкретно на каждого агрегата свой, то не так уже и медленно выходит. Мы так делали в гошных сервисах, когда агрегаты находятся непосредственно в памяти. Удобно.

    В остальных случаях мы считаем события как источник правды, но не обязательно событие должно применится без ошибки. В таком случае сейчас оно попадает в отдельную очередь кафки «failed queue», где обрабатывается позже.

    Текущее же состояние берется из read модели. Воркеры которые её обрабатывают работают достаточно быстро и также есть отдельный алгоритм, который определяет что делать в случае отставания.

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

    Но опять же повторюсь, что как по мне проблему конкуретной обработки решить универсальным способом достаточно сложно и нужно отталкиваться от контекста самой задачи.

    Підтримав: Max Shnurenok