Comments 12
Постоянно дрюкать огромную таблицу в базе на предмет наличия ключа идемпотентности будет сильно тормозить брокер. Если складывать в redis set или lru-кэш в памяти, то их память будет пухнуть под высокой нагрузкой. Нет ли каких-то готовых подходов к реализации идемпотентности?
Например, если у вас есть какое-то публичное api, то можно сделать метод генерации ключа и использовать завязанную на timestamp генерацию (uuid v7 или что-то свое). В этом случае за старым ключом можно сходить в базу, а за свежим в redis. Но это первое что пришло в голову, может кто-то уже погружался в тему и знает типовые промышленные подходы?
Если складывать в redis set или lru-кэш в памяти, то их память будет пухнуть под высокой нагрузкой
С правильным retention policy и ttl - не будет.
Но если redis упадет с потерей данных за последнюю секунду (параметр appendfsync everysec), то и ключи идемпотентности отвалятся.
Отдельная партиционированная по времени (например, каждый час) таблица для ключей более чем достаточна для большинства юзкейсов, если нужен суррогатный ключ. Старые партиции просто удалять.
Либо ключ должен быть частью данных как в случае с платежами и храниться вместе с данными.
Ещё интересный кейс, если поразмышлять дальше - когда потребитель проверил, что ключ не обработан. Далее у него выбор - отослать, к примеру, в платежный шлюз и потом сохранить в базу. Или наоборот. И снова у нас история с семантикой доставки) И обработкой идемпотентности уже у внешней системы.
Вот это спрашивать на интервью? Кажется, мы где-то свернули не туда...
Я правильно понял ,что это способ решить проблему, которая возможна лишь в микросервисной архитектуре, ведь в случае монолита мы все этапы пишем в рамках одной транзакции и описанных проблем нет в принципе?
Неправильно. Проблема возникает всегда при отправке в очереди. Ты либо в бд транзакцию а потом пытаешься отправить в очередь сообщение (может не случится), либо сначала отправляешь сообщение а потом пытаешься закомитить транзакцию
Prepod21, Дополню Spryka со своей стороны.
Здесь, скорее, случай больших распределенных систем. И этот кейс рассматривается в их контексте.
В случае монолита всё проще. Один процесс. Одна транзакция. И в монолите много логики по управлению складом, доставкой, ... . Нужно уметь хранить состояние такой многофакторной обработки. Считаем, что нет очередей.
В первом приближение, в монолите проще. По крайней мере, так можно обыграть на самом интервью. Глубже - трейдоффы и холивары в сообществах, на конференциях. На интервью не получится туда уйти с головой.
Поэтому, советую такой пайплайн прохождения:
Уточнение требований
Построение апи
Проектирование простейшей схемы с монолитом-first
а) И лишь затем переход к микросервисной архитектуре с обоснованием
б) И лишь затем накручивание таких паттернов, которые решают возникшие вызовы
Outbox relay постоянно опрашивает таблицу с определенной периодичностью. Верно?
Почему-то не могу избавится от ощущения костыльности этого решения.
И это хорошо!
Потому что System Design - это всегда трейдофф.
Мы перешли с монолита в микросервисы для масштабирования нашей системы. Смогли обслуживать высокие нагрузки. Вместе с этим, у нас возникли проблемы/challenges/вызовы. К примеру, возможная неконсистентность данных. Появилась нужда в распределенных транзакциях. В продумывании особенностей коммуникации между сервисами.
Придумали такое решение. Оно решило проблему. Как-то. У него есть свои преимущество и недостатки. Это нормально. И хорошо, что вы их чувствуете, замечаете.
Да, опрашивает таблицу с определенной периодичностью. Какие здесь есть недостатки?
Отлично! А то я наблюдаю аналитиков которые думают что добавят кафку и она сама по себе решит проблемы гарантированной доставки.
Осталось подумать над следующим шагом, а всегда ли нужен ли брокер в этой схеме?
RouR, мне страшно, когда у аналитиков спрашивают размер топиков в кафке. Недавно видел в сборнике интересных вопросов на аналитическом канале. Думаю, это too much.
Отличный вопрос про брокер. В классике идут вместе. Я так понимаю, подразумевается отказ от брокера в сторону прокачки воркера в полноценный http сервис, который отсылает сообщение другим сервисам?
Outbox pattern для System Design Интервью