Search
Write a publication
Pull to refresh
6
0
Владислав Коневский @Grosmaster

User

Send message

Тема интерсная, но с жатием json мы не эксперементировали. Решили воспользоваться опытом коллег из соседних проектов и останоивлись на avro.

Основная причина использования брокера сообщений заключается в желание снизить нагрузку на базу фронт-офиса и хранить данные уже на своей стороне.

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

Что касается стратегии доставки сообщений, мы выбрали подход At Least Once. Это решение гарантирует, что каждое сообщение будет записано как минимум один раз, и разработали алгоритм для обработки дубликатов. Для нас критически важно не потерять данные, поэтому стратегия At Most Once нам не подходит. В то же время, мы достаточно легко можем обрабатывать дубли, поэтому реализация Exactly Once выглядела бы избыточной.

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

Данные для клиринга поступают в двух форматах: через kafka из различных систем-источников и в виде файлов в формате платежной системы «Мир» от банков. Более подробно можно прочитать в нашей другой статье на хабре https://habr.com/ru/companies/oleg-bunin/articles/695262/

Information

Rating
Does not participate
Location
Москва, Москва и Московская обл., Россия
Date of birth
Registered
Activity

Specialization

Backend Developer
Lead