Как технически работает платформа лояльности и почему кешбэки при оплате по СБП приходят за считанные секунды?

Об этом рассказал наш коллега Константин Гузаров в своём докладе «Быстрые кешбэки для быстрых платежей», а мы собрали для тебя основные тезисы 👇

✅ Платформа лояльности интегрируется как с картами «Мир», так и с СБП, однако функционирует как отдельный сервис и не привязана напрямую к процессингу Мир или СБП — информацию по всем транзакциям она получает отдельно и начисляет кешбэки по заранее заданным маркетинговым акциям.

✅ Для кешбэков внутри СБП критичны высокие темпы обработки — расчёт и начисление должны укладываться в считанные секунды! Платформа делает это в лучших традициях СБП — мгновенно.

✅ Всё, что связано с мгновенной обработкой по СБП (контроль, расчёт, отправка кешбэка), вынесено в онлайн-часть. Вопросы отчётов, интеграций, регистрации, редактирования акций и прочего живут в офлайн-компонентах.

✅ Акции делятся на простые (например, процент с чека) и сложные (каждая третья покупка, суммы за месяц и др.), для сложных используется собственная система агрегатов и пересчётов. При возвратах происходит «холодный» пересчёт истории транзакций — чтобы кешбэк был точным, справедливым и защищённым от мошенничества.

✅ Платформа легко масштабируется горизонтально (Cassandra, Kafka), умеет обновляться без простоев и проводить A/B-тесты новых функций.

Хочешь больше подробностей? Тогда скорее смотри доклад!

В ИТ часто говорят про технологии. Но на самом деле всё держится на людях!

🌻 Сегодня знакомим тебя с тремя коллегами из Мир Plat.Form, которые занимаются разработкой, сертификацией и операционным ИТ. Поговорили с ними о профессии: что помогает расти, где в работе настоящий масштаб и какие навыки часто недооценивают.

Если хочешь поздравить коллег с 8 Марта, реакции под постом работают отлично 💙

Как работает эволюция схем данных в AVRO?

В Мир Plat.Form задача эволюции схемы данных AVRO стала острой на этапе внедрения новой интеграции между сервисами через Kafka. Вот 5 ключевых мыслей от коллег:

1️⃣ Почему важна эволюция схемы: сообщения в Kafka хранятся неделями, продюсеры и консьюмеры обновляются по-разному, и всем участникам нужно уметь читать разные версии схем данных, не ломая совместимость.

2️⃣ Версионирование топиков — не выход: изоляция схем через *_v1, *_v2 работает легко только внутри одной команды, а для кросс-команд, с частыми изменениями и переключениями, процессы становятся слишком громоздкими.

3️⃣ Schema Registry как стандарт: Confluent Schema Registry хранит версии схем, контролирует их совместимость (BACKWARD, FORWARD, FULL), автоматически определяет, как и что можно менять — и это необходимо для устойчивой работы.

4️⃣ Без Schema Registry: для временного решения можно добавить номер схемы прямо в хедер Kafka, чтобы на этапе десериализации легко сопоставлять данные и схему, не дорабатывая сериализатор (и не перелопачивая legacy).

5️⃣ Рекомендация: несмотря на устойчивость самописных решений с заголовками Kafka, для новых проектов рекомендуем переходить на Schema Registry — это автоматизация, минимизация ошибок и простота поддержки.

🔗 Подробнее читай в статье Владислава Коневского на Хабр.