Ledgerline
Open-source-платформа, сделана с Claude Code · Платёжная платформа, устроенная как банковская
Платёжная платформа, в которой деньги никогда не создаются, не теряются и не проводятся дважды: двойная запись на журнале событий, карточные платежи и выплаты как саги, outbox в Kafka, проверка на мошенничество в потоке, аналитика в ClickHouse, gRPC API для мерчантов и трассировка OpenTelemetry — всё доказано намеренными сбоями.
Задача
Платёжные системы проверяет день сбоя: потерянный ответ, упавшая база или повторный запрос не должны создать деньги, потерять их или провести дважды — а демо редко это показывают.
Решение
Леджер с двойной записью на журнале событий, саги, которые никогда не гадают, идемпотентность везде и outbox в Kafka, а затем хаос-тесты, нагрузочные тесты, модель мошенничества и оповещения — всё измерено, а не предположено.
Под капотом
Ни потерь, ни двойных проводок в 11 сценариях хаоса и 40 461 запросе; мошенничество поймано на 88% против 37% у правил; ~430 переводов/с на одном ядре; каждое оповещение проверено; онлайн-демо и CI.
Обзор
Ledgerline — open-source-платёжная платформа, которую я сделал с Claude Code, чтобы показать, что нужно ядру банка: деньги никогда не создаются, не теряются и не проводятся дважды, даже когда всё вокруг ломается. Леджер с двойной записью на Kotlin и Spring Boot ведёт неизменяемый журнал событий в PostgreSQL; остатки — проекции, восстанавливаемые из него, каждая запись идемпотентна, а аудит пересчитывает книги. Карточные платежи, возвраты и выплаты работают поверх него как конечные автоматы и саги, а каждое изменение попадает в Kafka через транзакционный outbox.
Это доказано сбоями под нагрузкой: сервисы, PostgreSQL и Kafka убиваются, сеть рвётся, ответы обрываются на середине, а клиент продолжает платить. В 11 сценариях хаоса и 40 461 запросе (4 188 из них отправлены дважды одновременно) проверка не нашла ни потерь, ни двойных проводок. Нагрузочные тесты нашли узкие места: леджер проводит около 430 переводов в секунду на одном ядре и отклоняет лишнее, а не падает.
Модель LightGBM на признаках из Kafka в реальном времени поймала 88% мошенничества при 0,7% ложных отказов против 37% у настроенных правил, по скрытой разметке симулятора; аналитика в ClickHouse сходится с леджером до копейки. Мерчанты получают gRPC API, подписанные вебхуки и SDK на TypeScript: когда сервис убили посреди платежа, все 1 085 изменений всё равно дошли до тестового магазина. Трассы идут за платежом через outbox, воркер и вебхуки, а каждое оповещение проверено внесением той неисправности, за которой оно следит.
Что делает
- Леджер с двойной записью на Kotlin и Spring Boot поверх неизменяемого журнала событий в PostgreSQL: идемпотентные операции, никакого ухода в минус при любой конкуренции и аудит, пересчитывающий книги
- Карточные платежи, возвраты и выплаты в смоделированный ненадёжный банк — конечные автоматы и саги; каждое изменение попадает в Kafka через транзакционный outbox
- Мошенничество оценивает в потоке модель LightGBM на признаках из Kafka, измеренная по скрытой разметке симулятора; аналитика в ClickHouse сходится с леджером до копейки
- gRPC API, подписанные вебхуки и SDK на TypeScript для мерчантов; трассы, идущие за платежом через outbox, воркер и вебхуки; SLO-оповещения, проверенные внесением каждой неисправности
Что дальше
Ищете full-stack- или Python-разработчика — или нужно сделать что-то похожее? Давайте обсудим.
Открыт к предложениям: офис или гибрид в Москве, либо удалённо; полная занятость или контракт. Отвечаю в течение 48 часов, в Telegram — быстрее.