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

1. Как правильно
считать деньги
в базе данных?
Роман Друзягин
технический директор, 404 Group

2. “Задачи разработки в вебе можно разделить
на две части: бухгалтерия, где все надо точно
учитывать, и рисование прогресс-баров.”

3. Любой web-ориентированный бизнес должен
считать деньги.
Многие делают это как попало.
Осознание важности вопроса приходит после
первой серьезной неприятности.

4. Причины?
 Отсутствие понимания предметной области.
 Отсутствие общей компетентности в области
Web-разработки.

5. Какие бывают неприятности?
Неправильно спроектировали.
Типичные симптомы:
 Не ясно, как добавить новый тип денежной операции.
 Биллинг вдруг “разъехался” и не понятно, как его чинить.

6. Какие еще бывают неприятности?
Неправильно внедрили.
Типичные симптомы:
 транзакции придумали трусы, давайте держать исходную
информацию для биллинга в Редисе;
 не понятно, почему количество денег в точке А не соответствует
количеству денег в точке Б;
 это нормально, когда база “упала” и потеряла при этом
немного денег (хорошо, если немного).

7. Еще неприятности?
Неправильно эксплуатируем.
Типичные симптомы:
 Подсчет денег периодически ставит “колом” полбазы.
 Ошибки внедрения (типа проблем с округлением и отсутствием
constraint checks) на больших объемах приобретают
катастрофический масштаб.

8. Что такое вообще двойная запись
и как ведется учет финансов?

9. Система двойной записи
 Придумана итальянскими купцами еще в XV веке.
 Проста и прозрачна.
 Будем использовать очень упрощенную схему.

10. Счета (согласно плану счетов):
 Активные и пассивные.
 Обладают номером и названием.
 Еще бывают субсчета, но это уже бухучет.
Расчет строится по принципу долга:
 Долг внешнего мира по отношению к нам (активы);
 Долг от нас внешнему миру (пассивы).

11. Дебет и кредит
Активные счета
 Дебет — приход средств.
 Кредит — расход.
Пассивные счета
 Дебет — расход средств.
 Кредит — приход.

12. Проводка
 ID,
 дата,
 первый счет,
 второй счет,
 сумма,
 комментарий.

13. Двойная запись
 Фиксируются приход и расход.
 Используется два счета.
 Для счета указывается способ использования.
 Деньги, откуда-то ушедшие, должны куда-то прийти!

14. Итого
Журнал проводок
 Двойная запись.
 Балансы не подводятся.
Главная книга
 Счет на странице.
 Номер проводки.
 Дата.
 Дебет.
 Кредит.
 Сальдо.

15. Как это работает?

16. Как это работает?

17. Как это работает?

18. Как это работает?

19. Что должна содержать система?
 Счета и типы счетов.
 Владельцы счетов и типы владельцев счетов.
 Типы операций в системе (транзакции с т.з. Бизнеса).
 Операционные периоды.
 Журнал проводок (“двойная запись”).
 Список бизнес-транзакций (“главная книга”).

20. Пример реализации для СУБД

21. Что дает эта модель?
 Простота в понимании.
 Расширяемость.
 Адекватность исполнения OLAP.
 Сравнительно невысокие накладные расходы на поддержание.
 Встроенные механизмы диагностики проблем.

22. Для среднестатической “Web-овой” системы этого
достаточно, чтобы взлететь.
Вменяемыми усилиями можно “прикрутить” стандартные
“хотелки” бизнеса: поддержка разных валют, “заморозка” средств,
подведение балансов (можно прикинуться “оперденью”) и др.

23. Важно!
Не делайте всю обработку денежных операций
“онлайново”.
Используйте очереди и асинхронную обработку.

24. Причины?
1. Масштабирование
При росте объемов легче будет расширять
процессинг всего этого хозяйства.

25. Причины?
2. Расширяемость
Имея очереди, проще интегрировать внешний сервис
с приемлемо гарантируемой корректностью
внесения средств.

26. Причины?
3. Обслуживание
Меньше проблем с диагностикой проблем конкурентного
доступа, осуществлением планового (и не очень)
downtime, и т.д.

27. Поиск проблем?
Такая система учета денег с высокой вероятностью гарантирует
поиск проблемы в пределах одной лишь таблицы – журнала
проводок.
Сумма проводок по конкретному типу транзакции должна
сходиться в ноль.
Для упрощения задачи диагностики можно заранее сделать ряд
хранимых процедур (или Web-интерфейс).

28. Что еще?
Этим способом можно (и нужно) учитывать не только деньги,
но и любые другие ценности, если подразумевается их
передача от одного лица другому.
Мы так считали выдачу и обмен баллов на
“ачивки” в социальной сети.

29. Вопросы?
Роман Друзягин
roman.druzyagin@404-group.com