Системы оплаты в транспорте — это не просто “купить билет онлайн”. Это инфраструктура, через которую проходят тысячи или миллионы транзакций каждый день.
Ошибка в архитектуре здесь стоит дорого: сбои, очереди, потеря денег и репутации.
Типичный сценарий:
Сначала запускается простая система: сайт + оплата. Через год появляются мобильные приложения, терминалы, валидаторы, интеграции. Через два — система начинает “ломаться” под нагрузкой.
Чтобы этого не происходило, такие решения нужно изначально проектировать как платформу, а не как сервис.
Из чего на самом деле состоит система оплаты
Современная ticketing-система — это несколько уровней:
- платёжный слой (карты, QR, NFC);
- билетная логика (тарифы, зоны, правила);
- валидация (контроль входа/выхода);
- учёт поездок;
- аналитика и отчёты;
- интеграции (банки, транспорт, ERP).
Все эти компоненты должны работать синхронно и без задержек.
Главная сложность — не оплата, а синхронизация
Многие думают, что самая сложная часть — это приём платежей. На практике — это координация всех систем.
- платёж прошёл, но билет не активировался;
- валидатор не получил данные;
- данные не дошли до аналитики;
- возник конфликт транзакций.
Именно поэтому архитектура должна быть event-driven и устойчивой к сбоям.
Как мы проектируем такие системы
Мы не начинаем с интерфейсов или функций. Мы начинаем с потоков:
- как проходит транзакция;
- где возникают задержки;
- какие данные критичны;
- где возможны ошибки.
После этого строится архитектура:
- разделение на сервисы;
- очереди и события;
- идемпотентность операций;
- устойчивость к сбоям;
- горизонтальное масштабирование.
Ключевые ошибки при разработке
- монолитная архитектура;
- отсутствие обработки ошибок;
- зависимость от одного платёжного провайдера;
- нет офлайн-режима;
- отсутствие real-time обновлений.
Такие решения работают до первой нагрузки или сбоя.
Что даёт правильная архитектура
- обработка тысяч транзакций в секунду;
- отказоустойчивость;
- масштабируемость;
- гибкость тарифов;
- интеграция с любыми системами.
Технологии, которые мы используем
- Node.js (NestJS) — backend логика
- Microservices — независимость сервисов
- Kafka / queues — обработка событий
- PostgreSQL — транзакционные данные
- Redis — кэш и скорость
- Docker / Kubernetes — масштабирование
От чего зависит стоимость
- количество каналов оплаты;
- сложность тарифной модели;
- интеграции;
- нагрузка системы;
- требования к отказоустойчивости.
Такие системы нельзя “дописать потом”
Если архитектура заложена неправильно, система не масштабируется. Её приходится переписывать.
Поэтому проектирование — это ключевой этап.
Оставьте заявку — мы покажем, как построить систему, которая выдержит рост.