Спроектируй цифровой кошелёк

Требования

Цифровой кошелёк держит баланс и даёт пользователям пополнять, тратить и переводить в другие кошельки. Числа малы, но планка корректности абсолютна.

Функциональные. Показать баланс. Кредитовать (пополнение) и дебетовать (трата) кошелёк. Переводить между двумя кошельками атомарно — дебет одного, кредит другого, никогда одно без другого. Отклонять дебет, что уводит в минус (если овердрафт явно не разрешён). Выдавать полную историю транзакций. Быть идемпотентным: повторённый перевод не должен двигать деньги дважды.

Нефункциональные. Корректность баланса необсуждаема — баланс всегда обязан равняться сумме движений кошелька, без потерянных обновлений и без создания или уничтожения денег. Переводы должны быть атомарными (обе ноги или ни одной). Операции должны быть идемпотентными под ретраями. Система должна масштабироваться до миллионов кошельков, что вынуждает шардинг — и вот тут переводы между шардами становятся трудными.

Пропускная способность скромна (кошелёк — не высокий-QPS фид), так что, ровно как с платежами, трудность — корректность под конкуренцией, а не сырой масштаб. Проблема потерянного обновления из вступления — враг, ради победы над которым существует весь дизайн.

Оценка

кошельков         = 100 000 000 кошельков
транзакций        = 50 000 000 переводов/день
средний QPS       = 5×10^7 / 86 400        ≈ 580 переводов/с  (скромно)
пик QPS           = ~5× средн.             ≈ 3 000 переводов/с
записей в ledger  = 2 на перевод (дебет + кредит) → ~10^8 неизменяемых строк/день
горячие кошельки  = пара кошельков продавцов могут забрать огромную долю записей

Совокупный QPS (~сотни до пары тысяч переводов/с) мал для БД. Дизайн на деле формируют две вещи. Первое — конкуренция за запись на кошелёк: большинство кошельков тихи, но популярный продавец или выплатной кошелёк может стать горячей точкой записи, и сериализация того единственного кошелька — реальное узкое место, а не общий итог. Второе — ledger растёт вечно (~10^8 записей/день, append-only, хранится годы), так что балансы выводятся из ledger, и нужен способ читать текущий баланс, не пересуммируя всю историю — снимок или материализованный баланс.

Высокоуровневый дизайн

Хребет — event sourcing: источник истины — append-only лог событий, меняющих баланс (кредитован, дебетован, переведён), а текущий баланс — это fold (свёртка) по этому логу, никогда не поле, что мутируешь на месте. Идемпотентность дедупит ретраи; перевод — единое атомарное применение (две записи ledger); балансы материализуются для быстрых чтений; а шардинг по wallet id держит большинство переводов одношардовыми, пока saga обрабатывает межшардовое меньшинство.

Глубокое погружение

Проблема потерянного обновления и контроль конкуренции

Вступление — каноничный баг конкуренции, и у него три стандартные починки — надо знать все три и когда какую.

Пессимистичная блокировка (SELECT … FOR UPDATE). Транзакция блокирует строку кошелька до чтения, так что второй перевод ждёт до коммита первого, затем читает свежий баланс ($30, не $100) и корректно отклоняет овердрафт. Просто и в точности корректно; цена — конкурентные операции на том же кошельке сериализуются, так что горячий кошелёк становится очередью.

Оптимистичная конкуренция (версия/CAS — Compare-And-Swap, сравни-и-запиши). Прочитай баланс и его версию, вычисли новый баланс, затем запиши только если версия не изменилась (UPDATE … WHERE id=? AND version=?). Если кто-то записал первым, версия сдвинулась, твоё обновление затрагивает ноль строк, и ты повторяешь со свежим значением. Хорошо, когда конкуренция редка (большинство кошельков); расточительно при высокой (шторм ретраев на горячем кошельке).

Атомарная условная запись. Затолкай весь check-and-decrement в один оператор, что БД исполняет атомарно: UPDATE wallets SET balance = balance - 70 WHERE id = ? AND balance >= 70. Гонки read-modify-write нет, потому что БД оценивает условие и обновление как одну операцию; ноль затронутых строк значит недостаточно средств. Это чистейший одношардовый дебет.

ПОТЕРЯННОЕ ОБНОВЛЕНИЕ (баг):
  T1 чит. 100 ─┐                    ┌─ T2 чит. 100
  T1 проверка  │  (оба видели 100)  │  T2 проверка
  T1 зап. 30 ──┘                    └─ T2 зап. 40   ← перезапис.; баланс = 40, потрачено $130

ПОЧИНЕНО (атомарная условная):
  T1: UPDATE … balance = balance-70 WHERE balance >= 70  → 1 строка, баланс = 30
  T2: UPDATE … balance = balance-60 WHERE balance >= 60  → 0 строк (30 < 60) → отклонён

Атомарные переводы и проблема межшарда

Перевод — это два движения — дебет отправителя, кредит получателя — что должны быть всё-или-ничего. Если оба кошелька на одном шарде/БД, это тривиально: оберни оба в одну локальную ACID-транзакцию; либо оба коммитятся, либо оба откатываются. Поэтому шардируешь по wallet id и стараешься держать связанные кошельки вместе — большинство переводов остаются одношардовыми и получают настоящую ACID-атомарность бесплатно.

Трудный случай — межшардовый перевод: отправитель на шарде A, получатель на шарде B, ни одна транзакция не охватывает оба. Нельзя просто дебетовать A, а затем кредитовать B — если кредит отказал после коммита дебета, деньги исчезли. Варианты:

• Saga с компенсацией (урок про event-driven): дебет A (локальный коммит) → кредит B (локальный коммит); если кредит B отказал, запусти компенсацию, кредитующую A назад. Между двумя шагами система кратко неконсистентна (деньги «в полёте»), что явно моделируется pending-состоянием.
• Двухфазный коммит (2PC): координатор готовит оба шарда, затем коммитит оба — сильная атомарность, но блокирует, если координатор умрёт посреди коммита, и связывает доступность со всеми участниками.

Большинство кошельков выбирают saga (доступна, eventually consistent, с явным in-flight состоянием) вместо 2PC (консистентен, но блокирует) и опираются на ledger плюс сверку, чтобы обнаружить и исцелить любой застрявший перевод.

Event sourcing: баланс как свёртка по событиям

Хранение баланса как изменяемого числа — первородный грех (это то, что включает потерянное обновление и стирает историю). Event sourcing переворачивает это: события — истина, баланс — производное. Каждое изменение — неизменяемое событие, добавленное в лог; текущий баланс вычисляется свёрткой событий:

события:  +100 (пополнение)  −70 (покупка)  +20 (возврат)
баланс = fold(0, события) = 0 + 100 − 70 + 20 = 50

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

Узкие места и компромиссы

Определяющее узкое место — сериализация записи на кошелёк: единственный горячий кошелёк (крупный продавец) — точка конкуренции, которую никакой шардинг не чинит, потому что нельзя разделить обновления баланса одного кошелька, не потеряв атомарность одной строки, что предотвращает потерянные обновления — смягчения это батчинг его обновлений или разбиение на суб-счета, что сверяются. Стратегия блокировки — компромисс по конкуренции: пессимистичные блокировки просты и безопасны, но сериализуют горячие кошельки; оптимистичная/CAS хороша при низкой конкуренции, но штормит ретраями при высокой; выбирай по профилю конкуренции кошелька. Межшардовые переводы меняют атомарность на доступность: одношардовый — настоящий ACID, межшардовый — saga с кратким in-flight расхождением и сверкой для исцеления опоздавших. И event sourcing меняет простоту чтения на целостность записи: чтениям нужны снимок-плюс-хвост, чтобы быть быстрыми, а хранилище растёт вечно, но взамен баланс всегда — проверяемое, аудитируемое следствие лога — компромисс, что денежные системы делают каждый раз.