Дополнительно:
- учесть, что сервис будет запускаться в k8s.
Сервис может запускаться через docker-compose, необходимо грамотно запустить миграции, через энтрипоинт
- учесть, что архитектура должна гарантировать обработку транзакции ровно 1 раз. Какие требования это накладывает на сам сервис и соседние сервисы?
Добавлен уникальный идентификатор транзакции, который передается сторонним сервисом. Сервисы могут проверять уникальность транзакции и не обрабатывать ее повторно, выдавая ошибку. Возможны иные варианты, в зав-ти от длительности транзакций, к примеру.
- описать (можно не реализовывать), как можно реализовать уведомление других сервисов о транзакциях. Например, уведомить рекламный движок, который работает при наличии средств на счету.
Брокеры сообщений, тригеры, вебсокеты, апи, можно напрямую писать в БД. Предпочтителен первый способ(селери, кролик, кафка в зав-ти от..)
- тезисно перечислить, какие инструменты можно применить для контроля качества работы сервиса.
Мониторинг, алертинг(прометус, графана, сентри, елк для логов). Чтобы было меньше багов можно нужно внедрить линтер, форматер, использовать их перед коммитами, внедрить кодстайл(уменьшает время на чтение кода), кросс ревью, тесты, и т.д
- гарантировать, что баланс пользователя не может быть отрицательным.
React
Typescript
Django
Laravel
Facebook
Microsoft
Google
Alibaba
D3
Tencent