Тезисы

Не так часто на конференциях рассказывают про архитектуру платежных систем, особенно если они делались без legacy. Нашей платежной системе всего три года, из которых два в продакшне. Мы изначально проектировали надежную и масштабируемую систему, и за прошедшее время накопилось тем для рассказа.

Я планирую коротко пройтись по архитектуре системы, останавливаясь на нестандартных вещах (тонкости работы с БД, особенности обеспечения безопасности, логирование и т.п.), и отдельно и подробно опишу то, как бизнес-требования выливались в конкретные архитектурные решения:
* как из требования "платеж - это много шагов, которые нужно надежно фиксировать" образовались персистентные акторы с гарантией доставки, как появление акторов в одной компоненте системы заставило пересмотреть все связанные компоненты;
* как ограничения на число коннекций к БД привели к реализации асинхронных сетевых вызовов;
* как рост цен на сервисы от MS привели нас к Vertica, и почему нам пришлось отказаться от ClickHouse;
* как требования PCI DSS привели к кластеризации всего и вся;
* зачем нам понадобилась своя CMS.

Будут велосипеды, реклама Java и PostgreSQL, признание собственных ошибок, стыд и гордость.
В результате я постараюсь рассказать, как делать не очень нагруженные, но надежные системы, живущие в мире enterprise, но пользуясь современными подходами к разработке.