🧮 Калькулятор ресурсов

Введи DAU и параметры профиля юзера — получишь требования по RAM/CPU/Disk + DB QPS на каждый сервис.

Сводная таблица ресурсов по всем сервисам

Применение методологии (00-methodology.md) к профилям сервисов (profiles/*.md) с распределением RPS из 10-rps-distribution.md.

Все цифры — суммарно: app + Postgres + Redis на сервис. Если сервис делит общую базу с другим — учитывай это отдельно.

Допущения:

- Включён 30% headroom для GC, шумных соседей, кратковременных пиков

- PG/Redis = standalone до 10k DAU, replica/cluster — выше

- CGO_ENABLED=1 (где есть)

- Buffer = +20% RAM на peak burst

---

Тиры архитектуры

---

Per-Service Sizing — суммарно (app + DB + Redis)

casino-core-service (medium)

casino-game-processing-service (heavy — orchestrator)

casino-wallet-service (heavy — financial critical)

casino-auth-service (heavy — token validation)

casino-bonuses-service (heavy — every bet)

casino-payment-service (heavy — PSP orchestrator)

casino-bi-service (analytics — write-heavy + slow reads)

BI > 10k DAU — мигрировать на ClickHouse. Postgres перестаёт справляться с aggregation queries.

casino-stats-service (write-heavy, аналог BI на меньшем масштабе)

casino-achievement-service (write-heavy через Kafka)

casino-back-office-service (admin only)

Особенность: RPS почти не растёт от DAU юзеров — только от количества админов (~50-200 на крупного клиента).

casino-config-service (read-heavy, агрессивный кеш)

casino-jackpot-service (atomic counters, kafka consumer)

casino-tournament-service (leaderboards via Redis)

casino-segmentation-service (5-second recalc loop)

casino-risk-management-service (sync withdraw path)

casino-sportsbook-service (Digitain webhook)

casino-balancer (geo-redirect)

Это лишь redirect-сервис, использует in-memory GeoIP — RPS легко масштабируется горизонтально.

casino-store-service (in-app store)

casino-partner-service (affiliate, polling-based)

casino-referral-service

casino-notifications-service (multi-channel fan-out)

Heavy: 4 Kafka consumer groups, 6 каналов, sync вызовы провайдеров.

---

Итого по платформе (без избыточности — single instance)

---

С учётом репликации и HA

Множители для T2+:

• PG: ×2 (primary + replica) или ×3 (primary + 2 replica)
• App: ×N подов для HA (минимум ×2)
• Redis: ×2 (master + replica) или ×6 (cluster 3+3)
• Kafka: 3 брокера (для T3+)

Финальный множитель к "сумме single instance": ~2.5× для T3, ~4× для T4.

---

Запросы к БД и Redis

Самая важная метрика для PG — DB QPS = HTTP RPS × queries_per_request. Часть запросов идёт мимо HTTP — через Kafka consumer'ов.

DB read QPS платформы (после кеша)

Write QPS преобладает над read в этой платформе — нагрузка финансово-транзакционная (wallet, bonuses, stats события). Это разворачивает обычные предположения "80% read / 20% write" в casino.

Pool sum (суммарно по всем сервисам)

Топ-3 сервиса по connections @ 1M DAU:

1. game-processing — 519 connections
2. wallet — 389 connections
3. bonuses — 138 connections

DB QPS по сервисам @ 100k DAU

Что переходит грань "PG не справится"

---

Топ-5 расходных статей

1. PostgreSQL master (wallet, bonuses, bi) — самый дорогой компонент
2. Kafka cluster (3+ брокера, 30 топиков) — стабильно ~10% стоимости
3. Redis (jackpot counters, leaderboards, session, cache) — растёт линейно
4. ClickHouse / analytics DB — обязателен для T3+ (вместо PG для bi/stats)
5. Egress traffic — для T4 значимая статья (CDN сильно помогает)

---

Что точно ЛОМАЕТСЯ при росте

Методология расчёта ресурсов

Этот документ описывает формулы и допущения, по которым считаются ресурсы для каждого сервиса (SIZING.md в репо сервиса) и для всей платформы (90-summary.md).

---

Профиль пользователя (casino)

Перевод DAU → RPS

RPS_avg = CCU × actions_per_minute / 60
       = (DAU × 0.08) × 8 / 60
       ≈ DAU × 0.0107

RPS_peak = RPS_avg × 3.0
        ≈ DAU × 0.032

Таблица RPS по тирам:

Распределение RPS по сервисам (средние коэффициенты по индустрии):

---

Сайзинг Go-сервиса

Базовая модель

Memory = idle_baseline + per_connection × concurrent_conns + per_RPS × RPS
CPU    = idle_baseline + per_RPS × RPS / efficiency_per_core

Числа по умолчанию (Go 1.25+, Gin/chi, sqlx/pgx)

Что классифицирует тяжесть:

• Light: простой CRUD, мало join'ов, мало бизнес-логики (≤ 30 routes, ≤ 15k LoC)
• Medium: умеренные join'ы, кеш, валидация, события Kafka (30-150 routes, 15-50k LoC)
• Heavy: сложная бизнес-логика, много join'ов, агрегаты, JSONB, тяжёлый Kafka (>150 routes, >50k LoC)

Концурентность

concurrent_conns = RPS_peak × avg_latency_seconds × safety_factor

Где:

• avg_latency = 50ms (light) / 100ms (medium) / 200ms (heavy)
• safety_factor = 2.0

---

Запросы к БД (Queries Per Request)

Самая важная метрика для сайзинга PG — это DB QPS = RPS × queries_per_request, а не просто HTTP RPS.

Таблица queries_per_request по типам сервисов

Профиль queries_per_request по сервису

Расчёт DB QPS

DB_QPS_peak = RPS_peak × queries_per_request × (1 - cache_hit_rate)

# с разбивкой:
DB_read_QPS  = RPS_peak × q_read  × (1 - cache_hit_rate)
DB_write_QPS = RPS_peak × q_write × 1.0  # writes не кешируются

Примечание о Kafka consumers: многие сервисы (stats, achievement, bi, bonuses, segmentation, risk-management) делают БОЛЬШЕ записей через Kafka consumers, чем через HTTP. Для них DB write QPS считается отдельно: events_per_second × q_write_per_event.

Готовая таблица DB QPS пиковых для топ-сервисов

Connection Pool Sizing

pool_size = MAX(10, CEIL(DB_QPS × avg_query_latency × safety))

С safety = 1.5 и avg_query_latency:

• light read = 5ms
• write = 10ms
• SELECT FOR UPDATE = 20ms
• aggregation = 200ms

Минимум pool на сервис = 10, иначе burst заблокирует все коннекты.

Critical: PG max_connections = 200 по умолчанию. После ~150 conns — обязательно PgBouncer в transaction mode (даёт 10-50× connections без роста реальных PG worker'ов).

Redis ops/sec

Redis_QPS = RPS_peak × redis_ops_per_request

Redis легко держит 100k+ QPS на одном инстансе для мелких ключей. Узкое место — сеть и сериализация.

---

Сайзинг PostgreSQL

Базовая модель

RAM_pg = shared_buffers + work_mem × max_connections × concurrent_queries_ratio + WAL + OS_cache
shared_buffers = 25% от total RAM
effective_cache_size = 50-75% от total RAM
work_mem = 4-16 MB (зависит от запросов)
max_connections = max(20, ceil(RPS_peak × 1.2 × num_services_per_db))

Сайзинг на основании юзеров

Storage

Storage_GB = (rows_per_user_per_day × avg_row_KB × DAU × retention_days) / 1024 / 1024 + indexes_overhead (~30%)

Типичные ставки записи:

• transactions — 50 строк / DAU / день (спины + депозиты + бонусы)
• bets — 200 строк / DAU / день
• events (analytics) — 500 строк / DAU / день (часто переносится в ClickHouse)
• audit_log — 30 строк / DAU / день

Connections

max_connections = N_services × pool_size_per_service

Типично pool = 10-25 на сервис. При 22 сервисах × 25 = до 550 коннектов.

Если коннектов > 200 — обязательно ставить PgBouncer (transaction pooling).

---

Сайзинг Redis

Базовая модель

RAM_redis = baseline (5 MB) + sum(cached_keys × avg_size) + replication_buffer (10%)

Что обычно кешируется

Сайзинг по DAU

---

Сайзинг Kafka

Производство для casino:

• 1 спин = 2-3 события (bet placed, balance changed, stats event)
• 1 депозит = 5-7 событий (incl. risk, bonus check, audit)
• avg event size = 1.5 KB

Kafka_throughput_msg_s = RPS_peak × events_per_request (avg 2.5)
Kafka_storage_GB_day = msg_per_sec × avg_event_KB × 86400 × replication / 1024 / 1024

---

Дисковая подсистема

---

Сетевые требования

egress_Mbps = RPS_peak × avg_response_KB × 8 / 1024

При avg_response = 5 KB:

---

Шкала тиров (для целевого SLA)

---

Допущения и ограничения

1. CGO_ENABLED=1 в большинстве сервисов — overhead ~5-10% RAM против чистого Go
2. JSONB-поля в PostgreSQL увеличивают I/O — учтено в "Heavy" категории
3. Без шардинга PG до 100k DAU; для 1M — обязательно шардирование transactions, bets
4. Replication factor: для T3+ Postgres = streaming replication; для T4 — synchronous replication между регионами
5. Cold start: после рестарта сервис прогревается 30-60 сек, в это время CPU x2 от sustained
6. GC pressure в Go: при больших аллокациях RAM = live_set × 2 для нормальной работы GOGC=100

---

Источники чисел

• Industry benchmarks: TechEmpower (Gin), pgbench, redis-benchmark
• Casino-specific: GLI/iGaming reports о среднем поведении игрока
• Internal: anonymized наблюдения за реальной нагрузкой Bethub

Распределение RPS по сервисам

Используется для перевода общего DAU → RPS на каждый сервис.

Веса по сервисам

Сумма не строго 100% — это эвристика. Используй с допуском ±20%.

Формула RPS на сервис

RPS_avg(service) = DAU × CCU_ratio × actions_per_min(service) / 60
RPS_peak(service) = RPS_avg × 3.0

Где:

• CCU_ratio = 0.08 (8% DAU онлайн в любой момент)
• actions_per_min(service) — из таблицы выше

Готовые цифры RPS_peak по сервисам

⚠️ peak coefficient 3× уже учтён.

Карта зависимостей сервисов

Получена из grep -r "SMC_*_SERVICE_URL" по всем репозиториям. Это synchronous HTTP вызовы между сервисами; асинхронные через Kafka — отдельно ниже.

Кто кого вызывает (sync HTTP)

Кто кого зовёт (inverted: «called by»)

Hot-path сервисы (вызываются на КАЖДОМ юзер-действии)

В порядке критичности latency:

1. auth — токен валидируется на каждом запросе → агрессивный кеш (Redis + in-process) обязателен
2. wallet — каждый spin = balance check + debit/credit → должен быть HA
3. config — кешируется, но запрашивается чаще всех → кеш в каждом сервисе на 5+ минут
4. bonuses — каждый bet проверяет wagering → кеш активных бонусов
5. segmentation — bonus eligibility и AB-tests → memoize per-request

Hub сервисы (вызываются 10+ другими)

Критические circular зависимости

• bonuses ↔ wallet: bonuses зовёт wallet (баланс), wallet зовёт bonuses (bonus balance)
• Решение: сделать wallet "источник правды" по балансам, bonuses не зовёт wallet sync

• core ↔ stats: core зовёт stats (chat events), stats зовёт core (?)
• Проверить — в случае циркулярной зависимости вынести events в Kafka

Мёртвый код / стабы

• notifications-service — пустой (0 LoC). Если нужны notifications — реализовать отдельно
• boilerplate-service — template для новых сервисов, не разворачивается

Внешние зависимости (3rd-party)

Граф зависимостей (Mermaid)

Sync HTTP-зависимости (упрощённая)

Легенда

• 🟡 Hub (auth, wallet, config, stats, back-office, bonuses, notifications, segmentation) — вызываются многими; нужны read replicas / агрессивный кеш
• 🔴 Hot path (game-processing) — входная точка spin'а, fan-out на 15 сервисов
• 🟦 Critical (risk-management) — sync-блокирует payment/withdraw, latency-sensitive
• 🟢 Analytics (bi, dashed lines) — consumer-side через Kafka, sync-вызовы редкие
• ⚪ External (sportsbook=Digitain, payment=PSPs, balancer=Cloudflare) — есть 3rd-party

---

Kafka-связи (упрощённо)

Hot Path: один спин — какие сервисы трогаются?

Затраты времени по компонентам spin'а (~150ms типовой)

При cache miss на auth + slow wallet → могут быть >500ms даже при быстром провайдере. Cache hit на auth обязателен.

Тиры архитектуры

Шкала привязки DAU к архитектурному паттерну.

Все сервисы (22)

casino-core-service

medium Доля общего RPS: 25%

Что растёт линейно с DAU

• Chat messages — самая растущая таблица, ~3 сообщений/CCU/мин
• Story views — каждый show = upsert (с unique constraint)
• App RAM — 1-2 MB на 10 RPS

Что растёт ступенями (нелинейно)

• При 10k+ CCU — chat partitioning по datetime
• Story view upsert contention — на популярные stories спайки

Узкое место

Что сломается первым: chat_messages таблица растёт неконтролируемо

Когда: ~50,000 DAU

Как обойти: Партиционировать chat_messages по дате; old chats → cold storage; rate-limit на chat send

Минимальные ресурсы по DAU

Включает app + Postgres + Redis (single instance, +30% headroom). Для HA умножай app ×2-4, DB ×2.

Запросы к БД и Redis

Профиль: 2.5 q/HTTP-request (read: 2.4, write: 0.1), Redis: 0.5 ops/req, cache hit: 80%, avg query latency: 10 ms

Pool sizing: MAX(10, ceil((rd_QPS + wr_QPS) × avg_query_ms / 1000 × 1.5))

Особенности и риски

• CMS + chat — открытие любой страницы. Hub для контента.
• Admin chat ban list часто опрашивается — кеш в Redis обязателен.
• Story view кафка-продьюсер: при 1M DAU peak ~2k events/sec на топик.

Связи

См. граф зависимостей и Mermaid-диаграмму.

casino-game-processing-service

heavy Доля общего RPS: 20%

Что растёт линейно с DAU

• game_actions — 1 row/spin = 200 rows/DAU/day
• RAM app — 2-3 MB на 10 RPS (orchestrator, держит state)
• Outbound HTTP коннекты в wallet/bonuses/etc

Что растёт ступенями (нелинейно)

• Provider HTTP latency — скачок при их API throttling
• Game catalog cache invalidation — каждые 2 часа полный rebuild
• При 100k+ DAU — game_actions партиционирование по date обязательно

Узкое место

Что сломается первым: Sync HTTP вызов wallet — wallet p99 latency напрямую = spin latency

Когда: ~10,000 DAU

Как обойти: Circuit breaker на wallet calls; bulk Kafka events; партицирование game_actions; реплики app

Минимальные ресурсы по DAU

Включает app + Postgres + Redis (single instance, +30% headroom). Для HA умножай app ×2-4, DB ×2.

Запросы к БД и Redis

Профиль: 6.0 q/HTTP-request (read: 4.0, write: 2.0), Redis: 1.0 ops/req, cache hit: 60%, avg query latency: 15 ms

Pool sizing: MAX(10, ceil((rd_QPS + wr_QPS) × avg_query_ms / 1000 × 1.5))

Особенности и риски

• Spin orchestrator — fan-out на 15 сервисов. Самый горячий путь.
• game_actions table растёт неограниченно (1 строка на spin) — нужно партиционирование @ >10k DAU.
• Sync HTTP вызов wallet — wallet p99 latency напрямую влияет на spin SLA.
• Provider callbacks (Softswiss/Slotegrator/Zenith/Hub88) — внешний latency может всплывать.

Связи

См. граф зависимостей и Mermaid-диаграмму.

casino-wallet-service

heavy (financial-critical) Доля общего RPS: 15%

Что растёт линейно с DAU

• transactions — 400 rows/DAU/day; самая большая таблица
• DB write QPS = 3 × RPS — каждая транзакция = 3 INSERT/UPDATE
• Redis balance cache — 0.5 KB на CCU юзер, TTL 30s

Что растёт ступенями (нелинейно)

• SELECT FOR UPDATE row lock — на горячих юзерах queue растёт нелинейно
• WAL throughput — при 1k+ wQPS нужен NVMe + отдельный диск под WAL
• При 100k DAU — read replica для отчётов (выгрузки)
• При 1M DAU — шардинг по user_id (минимум 4 шарда)

Узкое место

Что сломается первым: Lock contention на balance row у активных юзеров (whale users)

Когда: ~50,000 DAU

Как обойти: Балансы в Redis с периодической сверкой; шардинг transactions по user_id; партицирование по дате; pgBouncer transaction mode

Минимальные ресурсы по DAU

Включает app + Postgres + Redis (single instance, +30% headroom). Для HA умножай app ×2-4, DB ×2.

Запросы к БД и Redis

Профиль: 5.0 q/HTTP-request (read: 2.0, write: 3.0), Redis: 1.0 ops/req, cache hit: 70%, avg query latency: 15 ms

Pool sizing: MAX(10, ceil((rd_QPS + wr_QPS) × avg_query_ms / 1000 × 1.5))

Особенности и риски

• ACID критично: SELECT FOR UPDATE на каждой транзакции.
• transactions table — самая большая таблица. Партиционирование по user_id обязательно @ >100k DAU.
• При 1M DAU — шардинг по user_id (2-4 шарда минимум).
• Read replica для отчётов back-office чтобы не блокировать primary.
• TruePlay sync HTTP — может стопорить game-action consumer; добавить timeout + DLQ.

Связи

См. граф зависимостей и Mermaid-диаграмму.

casino-auth-service

heavy (universal hot path) Доля общего RPS: 5%

Что растёт линейно с DAU

• RAM app — растёт ~+0.5 MB на каждые 10 RPS (concurrent goroutines)
• PG sessions table — линейно по DAU (~5 KB/юзер при средней сессии)
• Redis token cache — линейно по CCU (~2 KB/юзер)

Что растёт ступенями (нелинейно)

• DB CPU — скачком при потере кеш-хита (например, 95% → 90%)
• При 100k+ DAU — нужен read replica для админских запросов
• При 1M DAU — переход sessions из PG в Redis даёт -70% DB load

Узкое место

Что сломается первым: Token validation latency — если cache miss > 5%, PG не справляется

Когда: ~30,000 DAU

Как обойти: Redis-only sessions + JWT stateless (denylist в Redis)

Минимальные ресурсы по DAU

Включает app + Postgres + Redis (single instance, +30% headroom). Для HA умножай app ×2-4, DB ×2.

Запросы к БД и Redis

Профиль: 1.5 q/HTTP-request (read: 1.5, write: 0.0), Redis: 1.0 ops/req, cache hit: 95%, avg query latency: 15 ms

Pool sizing: MAX(10, ceil((rd_QPS + wr_QPS) × avg_query_ms / 1000 × 1.5))

Особенности и риски

• Token validation на каждом запросе всех сервисов — кеш Redis ОБЯЗАТЕЛЕН.
• Сейчас sessions хранятся в Postgres — миграция в Redis снимает 70% нагрузки на DB.
• SMS/email/SumSub/Fingerprint.js — переменные затраты per-user. Бюджетировать отдельно.
• При 1M DAU рассмотреть JWT stateless с denylist в Redis вместо DB sessions.

Связи

См. граф зависимостей и Mermaid-диаграмму.

casino-bonuses-service

heavy (every bet) Доля общего RPS: 10%

Что растёт линейно с DAU

• wagering_log — 1 row на bet (через Kafka consumer)
• user_bonuses growth = sum активных бонусов × кол-во юзеров
• Redis active_bonus cache — 1 KB/CCU

Что растёт ступенями (нелинейно)

• Скачок при крупных промо-кампаниях (free spins для всех = единоразовый INSERT batch)
• Asynq queue (5 cron) — фиксированные пики времени
• При 100k DAU — отдельный consumer для game-action.created

Узкое место

Что сломается первым: Kafka consumer lag на game-action.created — wagering progress отстаёт

Когда: ~30,000 DAU

Как обойти: Increase consumer parallelism; batch updates; кеш активных бонусов в Redis HASH; партицирование wagering_log

Минимальные ресурсы по DAU

Включает app + Postgres + Redis (single instance, +30% headroom). Для HA умножай app ×2-4, DB ×2.

Запросы к БД и Redis

Профиль: 4.0 q/HTTP-request (read: 3.0, write: 1.0), Redis: 2.0 ops/req, cache hit: 70%, avg query latency: 15 ms

Pool sizing: MAX(10, ceil((rd_QPS + wr_QPS) × avg_query_ms / 1000 × 1.5))

Особенности и риски

• Wagering progress — каждый bet триггерит update. Самый высокий write rate из всех сервисов.
• Active bonuses cache в Redis обязателен — иначе DB не справится.
• Asynq queue (5 scheduled jobs) — отдельный worker.
• Кафка consumer game-action.created — рассмотреть batch processing для @ >100k DAU.

Связи

См. граф зависимостей и Mermaid-диаграмму.

casino-payment-service

heavy (PSP orchestrator) Доля общего RPS: 1%

Что растёт линейно с DAU

• payment_orders — линейный, 0.2 row/DAU/day (deposits)
• PSP webhook traffic — независимый от DAU (зависит от транзакций)

Что растёт ступенями (нелинейно)

• PSP webhook bursts — могут давать пик x10 от среднего
• При смене PSP — изоляция новой интеграции
• Crypto deposits подтверждения — другой паттерн (long polling)

Узкое место

Что сломается первым: Idempotency на webhook'ах — без партиционирования payment_orders медленнее с ростом

Когда: ~100,000 DAU

Как обойти: Партицирование payment_orders по месяцу; архив PG → S3 после 1 года; rate-limit на PSP webhooks

Минимальные ресурсы по DAU

Включает app + Postgres + Redis (single instance, +30% headroom). Для HA умножай app ×2-4, DB ×2.

Запросы к БД и Redis

Профиль: 4.0 q/HTTP-request (read: 2.0, write: 2.0), Redis: 0.5 ops/req, cache hit: 30%, avg query latency: 15 ms

Pool sizing: MAX(10, ceil((rd_QPS + wr_QPS) × avg_query_ms / 1000 × 1.5))

Особенности и риски

• 15 PSP интеграций — каждая со своими webhook'ами и rate limit'ами.
• Idempotency через payment_orders — таблица не партиционирована, нужно архивировать.
• Webhook bursts от PSP могут давать пик x10 от среднего — плотный rate limit.
• in-process cache (10min TTL) — cold restart даёт спайк к зависимостям.

Связи

См. граф зависимостей и Mermaid-диаграмму.

casino-bi-service

heavy (analytics) Доля общего RPS: 0%

Что растёт линейно с DAU

• events table растёт пропорционально всей платформы (Kafka из всех сервисов)
• PG disk — единственный сильно растущий компонент (без партицирования = катастрофа)

Что растёт ступенями (нелинейно)

• Aggregation queries — резкий скачок latency после 100M строк в events
• При >10k DAU — миграция на ClickHouse даёт сжатие 10× и скорость 100×

Узкое место

Что сломается первым: Aggregation queries блокируют write transactions

Когда: ~10,000 DAU

Как обойти: ClickHouse для events; PG только для metadata; materialized views для частых отчётов

Минимальные ресурсы по DAU

Включает app + Postgres + Redis (single instance, +30% headroom). Для HA умножай app ×2-4, DB ×2.

Запросы к БД и Redis

Профиль: 0.5 q/HTTP-request (read: 0.5, write: 0.0), Redis: 0.1 ops/req, cache hit: 20%, avg query latency: 200 ms

Pool sizing: MAX(10, ceil((rd_QPS + wr_QPS) × avg_query_ms / 1000 × 1.5))

Особенности и риски

• **МИГРИРОВАТЬ НА CLICKHOUSE @ >10k DAU.** Postgres не справится с aggregations.
• Pure Kafka consumer — 46 топиков из всей платформы.
• Нет materialized views — все отчёты считают на лету.
• Disk @ 1M DAU = 50 TB / год; ClickHouse сжимает в 10x.

Связи

См. граф зависимостей и Mermaid-диаграмму.

casino-stats-service

medium-heavy (write-heavy) Доля общего RPS: 5%

Что растёт линейно с DAU

• transactions table — 1 row на event из Kafka
• Aggregation jobs — фиксированная нагрузка независимо от DAU

Что растёт ступенями (нелинейно)

• При >100k DAU — аналогично BI, ClickHouse
• Anti-fraud turnover queries замедляются при больших суммарных таблицах

Узкое место

Что сломается первым: Aggregation на events table при write нагрузке

Когда: ~50,000 DAU

Как обойти: Партицирование events по date; read replica для aggregation; хот-кеш топ-метрик в Redis

Минимальные ресурсы по DAU

Включает app + Postgres + Redis (single instance, +30% headroom). Для HA умножай app ×2-4, DB ×2.

Запросы к БД и Redis

Профиль: 1.2 q/HTTP-request (read: 0.0, write: 1.2), Redis: 0.0 ops/req, cache hit: 0%, avg query latency: 10 ms

Pool sizing: MAX(10, ceil((rd_QPS + wr_QPS) × avg_query_ms / 1000 × 1.5))

Особенности и риски

• transactions table append-only без партиций — критическая проблема >100k DAU.
• Кандидат на ClickHouse @ >100k DAU.
• Aggregation jobs (NGR, GGR) — тяжёлые, на read replica если возможно.
• Anti-fraud turnover checks — sync hot path на withdrawals.

Связи

См. граф зависимостей и Mermaid-диаграмму.

casino-achievement-service

medium-heavy (kafka fan-in) Доля общего RPS: 2%

Что растёт линейно с DAU

• user_achievements — рост ~ N achievements × N users
• Kafka throughput — 21 топика consumed
• user_points — append на каждый event

Что растёт ступенями (нелинейно)

• Leaderboards refresh — фиксированный фоновый CPU
• При >100k DAU — партицирование user_achievements обязательно
• In-process LRU dedup — НЕ shared между replicas → дубли при scale-out

Узкое место

Что сломается первым: Kafka consumer lag (game-action.created в 2 группах)

Когда: ~30,000 DAU

Как обойти: Внешний dedup через Redis SET; партицирование user_achievements; consumer parallelism +

Минимальные ресурсы по DAU

Включает app + Postgres + Redis (single instance, +30% headroom). Для HA умножай app ×2-4, DB ×2.

Запросы к БД и Redis

Профиль: 3.0 q/HTTP-request (read: 1.0, write: 2.0), Redis: 0.5 ops/req, cache hit: 40%, avg query latency: 10 ms

Pool sizing: MAX(10, ceil((rd_QPS + wr_QPS) × avg_query_ms / 1000 × 1.5))

Особенности и риски

• 21 Kafka topics consumed — самый широкий fan-in в платформе.
• user_achievements/user_points high-churn tables — партиционирование обязательно.
• In-process LRU dedup — НЕ shared между replicas, риск дублей.
• 2 consumer groups на game-action.created — мониторить лаги отдельно.

Связи

См. граф зависимостей и Mermaid-диаграмму.

casino-back-office-service

medium (admin only) Доля общего RPS: 0% (admin RPS)

Что растёт линейно с DAU

• go_admin_logs — растёт по числу админов и активности
• Дашборды грузят данные из других сервисов

Что растёт ступенями (нелинейно)

• Большие отчёты — burst CPU (можно использовать read replica)
• Audit log retention — нужна архивация после 1 года

Узкое место

Что сломается первым: go_admin_logs растёт неограниченно

Когда: ~1,000,000 DAU

Как обойти: Архивация audit_log в S3 после 1 года; reports через read replica; sticky sessions

Минимальные ресурсы по DAU

Включает app + Postgres + Redis (single instance, +30% headroom). Для HA умножай app ×2-4, DB ×2.

Запросы к БД и Redis

Профиль: 4.0 q/HTTP-request (read: 4.0, write: 0.0), Redis: 1.0 ops/req, cache hit: 90%, avg query latency: 10 ms

Pool sizing: MAX(10, ceil((rd_QPS + wr_QPS) × avg_query_ms / 1000 × 1.5))

Особенности и риски

• RPS зависит от количества админов (~50-200), а не от DAU юзеров.
• go_admin_logs (audit) — единственная растущая таблица. Retention 1-2 года.
• user_sessions в Redis без TTL — рестарт Redis = логаут всех админов. Использовать persistent.

Связи

См. граф зависимостей и Mermaid-диаграмму.

casino-config-service

light (read-cached) Доля общего RPS: 0.3%

Что растёт линейно с DAU

• Почти ничего — конфиги фиксированные
• Read traffic растёт пропорционально кол-ву app-инстансов (а не DAU)

Что растёт ступенями (нелинейно)

• При >100 app-инстансов — кеш в каждом помогает
• Bulk update — N+1 запросов

Узкое место

Что сломается первым: Cache invalidation race на bulk updates

Когда: ~1,000,000 DAU

Как обойти: Локальный кеш в каждом сервисе с TTL 5 мин; pub/sub invalidation

Минимальные ресурсы по DAU

Включает app + Postgres + Redis (single instance, +30% headroom). Для HA умножай app ×2-4, DB ×2.

Запросы к БД и Redis

Профиль: 0.05 q/HTTP-request (read: 0.05, write: 0.0), Redis: 1.0 ops/req, cache hit: 99%, avg query latency: 5 ms

Pool sizing: MAX(10, ceil((rd_QPS + wr_QPS) × avg_query_ms / 1000 × 1.5))

Особенности и риски

• Hit rate в Redis cache > 99% — Postgres почти простаивает.
• Кафки нет (env vars присутствуют, но не используются).
• BulkUpdate — N+1 pattern, при тысячах ключей будет медленно.
• Cache invalidation не атомарна с DB write — race в крайних случаях.

Связи

См. граф зависимостей и Mermaid-диаграмму.

casino-jackpot-service

medium (atomic counters) Доля общего RPS: 3%

Что растёт линейно с DAU

• game_action_for_jackpots — 1 row/bet
• INCR на jackpots.current_winning_amount — горячий row

Что растёт ступенями (нелинейно)

• Win event — единоразовый burst (notification + payout)
• Cron 10-min winner selection — фиксированный пик

Узкое место

Что сломается первым: Hot row write на jackpots row под высокой bet rate

Когда: ~30,000 DAU

Как обойти: Перенести counter в Redis INCRBYFLOAT; периодически (1-min) flush в DB; партицирование game_action_for_jackpots

Минимальные ресурсы по DAU

Включает app + Postgres + Redis (single instance, +30% headroom). Для HA умножай app ×2-4, DB ×2.

Запросы к БД и Redis

Профиль: 2.0 q/HTTP-request (read: 1.0, write: 1.0), Redis: 1.0 ops/req, cache hit: 80%, avg query latency: 10 ms

Pool sizing: MAX(10, ceil((rd_QPS + wr_QPS) × avg_query_ms / 1000 × 1.5))

Особенности и риски

• Hot row write на jackpots.current_winning_amount — переносить в Redis INCRBYFLOAT.
• game_action_for_jackpots — без retention, расти будет миллиардами строк.
• Cron 10-min winner selection — multi-step transaction + sync wallet payout.
• При 1M DAU переход на Redis-only counters обязателен.

Связи

См. граф зависимостей и Mermaid-диаграмму.

casino-tournament-service

medium (leaderboards) Доля общего RPS: 2%

Что растёт линейно с DAU

• tournament_participants — растёт по числу активных турниров × DAU
• leaderboard updates — 1 ZADD на bet в активном турнире

Что растёт ступенями (нелинейно)

• End-of-tournament batch payout — фиксированный пик (sync wallet calls)
• При >10k участников — leaderboard паджинация обязательна

Узкое место

Что сломается первым: Sync wallet calls в end-of-tournament payout

Когда: ~100,000 DAU

Как обойти: Async payout через Kafka + worker; Redis ZSET для leaderboard; chunk payout (200/sec)

Минимальные ресурсы по DAU

Включает app + Postgres + Redis (single instance, +30% headroom). Для HA умножай app ×2-4, DB ×2.

Запросы к БД и Redis

Профиль: 2.5 q/HTTP-request (read: 1.5, write: 1.0), Redis: 2.0 ops/req, cache hit: 90%, avg query latency: 10 ms

Pool sizing: MAX(10, ceil((rd_QPS + wr_QPS) × avg_query_ms / 1000 × 1.5))

Особенности и риски

• Redis sorted sets (ZSET) — обязательно для leaderboards.
• End-of-tournament batch payout (sync wallet calls) — фиксированный пик.
• Tie-break logic — внимательно с consistency между Redis cache и DB.

Связи

См. граф зависимостей и Mermaid-диаграмму.

casino-segmentation-service

medium (recalc loop) Доля общего RPS: 2%

Что растёт линейно с DAU

• segmentation_users — линейно по числу сегментов × юзеров
• 5-секундный recalc loop — фоновый CPU постоянный

Что растёт ступенями (нелинейно)

• Большие сегменты с правилами на stats — медленная переоценка
• Каждый новый сегмент = +5%-10% постоянной нагрузки

Узкое место

Что сломается первым: 5-сек recalc loop под большим количеством сегментов

Когда: ~50,000 DAU

Как обойти: Дельта-recalc вместо full; кеш сегментов в Redis 30 sec; разделить cron heavy/light сегментов

Минимальные ресурсы по DAU

Включает app + Postgres + Redis (single instance, +30% headroom). Для HA умножай app ×2-4, DB ×2.

Запросы к БД и Redis

Профиль: 3.0 q/HTTP-request (read: 2.0, write: 1.0), Redis: 0.5 ops/req, cache hit: 70%, avg query latency: 5 ms

Pool sizing: MAX(10, ceil((rd_QPS + wr_QPS) × avg_query_ms / 1000 × 1.5))

Особенности и риски

• 5-секундный recalc loop — при больших сегментах фоновый CPU будет постоянно высоким.
• Asynq concurrency 30 — настраивай отдельно от HTTP концурентности.
• Membership чтения — без Redis cache, при росте DAU добавить кеш на 30-60 сек.
• WebSocket индирект через notification-service.

Связи

См. граф зависимостей и Mermaid-диаграмму.

casino-risk-management-service

medium (sync withdraw path) Доля общего RPS: 2%

Что растёт линейно с DAU

• risk_events — 1 row на каждое значимое событие (deposit, withdraw)
• alerts — линейно от триггеров правил
• PEP cache в Redis — 24h TTL

Что растёт ступенями (нелинейно)

• Регуляторное хранение 5-7 лет = unbounded growth без партицирования
• Sync withdraw path — latency-critical
• PEP/AML провайдер (Dilisense) rate limit — спайки на регистрациях

Узкое место

Что сломается первым: risk_events table grows; sync /scoring-system latency блокирует withdrawals

Когда: ~50,000 DAU

Как обойти: Партицирование events по месяцу + холодное в S3; bloom filter для blacklist; circuit breaker на PEP

Минимальные ресурсы по DAU

Включает app + Postgres + Redis (single instance, +30% headroom). Для HA умножай app ×2-4, DB ×2.

Запросы к БД и Redis

Профиль: 3.0 q/HTTP-request (read: 2.0, write: 1.0), Redis: 1.0 ops/req, cache hit: 80%, avg query latency: 10 ms

Pool sizing: MAX(10, ceil((rd_QPS + wr_QPS) × avg_query_ms / 1000 × 1.5))

Особенности и риски

• **Регуляторное хранение 5-7 лет** — партиционирование событий + холодное хранилище.
• Sync hot path на /scoring-system + /risk-summary в payment withdraw flow — latency-critical.
• PEP/AML провайдер (Dilisense) — sync HTTP, добавить circuit breaker.
• Blacklist должен быть в Redis (или bloom filter) для быстрых lookup.

Связи

См. граф зависимостей и Mermaid-диаграмму.

casino-sportsbook-service

medium (Digitain webhook) Доля общего RPS: 4%

Что растёт линейно с DAU

• bet_operations — 1 row/bet через Digitain webhook
• Sessions — 1 row на старт/конец сессии

Что растёт ступенями (нелинейно)

• Burst при старте популярных матчей (live betting)
• Settlement runs пакетные — стабильный пик
• При 10k+ — нужен Redis для auth token cache (сейчас sync HTTP к auth)

Узкое место

Что сломается первым: Auth-сервис latency на каждом webhook — нет локального кеша

Когда: ~10,000 DAU

Как обойти: Добавить Redis для auth token cache; шардинг сессий; rate-limit на DebitByBatch

Минимальные ресурсы по DAU

Включает app + Postgres + Redis (single instance, +30% headroom). Для HA умножай app ×2-4, DB ×2.

Запросы к БД и Redis

Профиль: 5.0 q/HTTP-request (read: 3.0, write: 2.0), Redis: 0.2 ops/req, cache hit: 30%, avg query latency: 10 ms

Pool sizing: MAX(10, ceil((rd_QPS + wr_QPS) × avg_query_ms / 1000 × 1.5))

Особенности и риски

• Redis сейчас 0 — нужно добавить хотя бы для auth token cache (DOS защита).
• Digitain webhook DebitByBatch/RollBackByBatch — внутри multi-step DB transaction + Kafka.
• Burst при старте популярных матчей — горизонтальное масштабирование подов.
• Settlement runs пакетные — мониторить хвост хвоста.

Связи

См. граф зависимостей и Mermaid-диаграмму.

casino-balancer

light (geo-redirect) Доля общего RPS: 0.1%

Что растёт линейно с DAU

• Memory — почти не растёт (GeoIP2 фиксированный, ~100 MB)
• DB — domain registry, фиксированный размер

Что растёт ступенями (нелинейно)

• Provisioning workflows — внешние API rate limits (Cloudflare/Namecheap)
• Domain мониторинг — фиксированный фоновый трафик

Узкое место

Что сломается первым: Внешние API провайдеров (Cloudflare/Namecheap rate limits)

Когда: ~1,000,000 DAU

Как обойти: Горизонтальное масштабирование (stateless); кеш GeoIP lookup в Redis; queue провижионинга

Минимальные ресурсы по DAU

Включает app + Postgres + Redis (single instance, +30% headroom). Для HA умножай app ×2-4, DB ×2.

Запросы к БД и Redis

Профиль: 1.0 q/HTTP-request (read: 1.0, write: 0.0), Redis: 0.0 ops/req, cache hit: 0%, avg query latency: 5 ms

Pool sizing: MAX(10, ceil((rd_QPS + wr_QPS) × avg_query_ms / 1000 × 1.5))

Особенности и риски

• Это NOT load balancer — это geo-routing service (mirror domains).
• GeoIP2 in-memory — 100 MB на инстанс, легко горизонтально масштабируется.
• Domain provisioning через Cloudflare/Namecheap/PSKZ — внешние API rate limits.
• Не на критическом пути — failover на DNS-уровне.

Связи

См. граф зависимостей и Mermaid-диаграмму.

casino-store-service

light Доля общего RPS: 2%

Что растёт линейно с DAU

• user_products — 1 row на покупку
• purchase logs — append-only

Что растёт ступенями (нелинейно)

• При больших промо — burst закупок
• Inventory consistency — race conditions в multi-service flow

Узкое место

Что сломается первым: Sync wallet/bonus/achievement calls на каждую покупку

Когда: ~100,000 DAU

Как обойти: Inventory hold + async fulfillment; Saga pattern для distributed transaction

Минимальные ресурсы по DAU

Включает app + Postgres + Redis (single instance, +30% headroom). Для HA умножай app ×2-4, DB ×2.

Запросы к БД и Redis

Профиль: 4.0 q/HTTP-request (read: 2.0, write: 2.0), Redis: 0.5 ops/req, cache hit: 60%, avg query latency: 5 ms

Pool sizing: MAX(10, ceil((rd_QPS + wr_QPS) × avg_query_ms / 1000 × 1.5))

Особенности и риски

• Каждая покупка делает 3-4 sync вызова (wallet, bonus, achievement, auth) — нет distributed transaction.
• Inventory consistency: race условия между local insert и remote wallet charge.
• Use goose migrations (другой инструмент чем у большинства).

Связи

См. граф зависимостей и Mermaid-диаграмму.

casino-partner-service

light (polling) Доля общего RPS: 0.5%

Что растёт линейно с DAU

• affilka_users — линейно по новым регистрациям
• manual_user_activity — растёт по кол-ву событий
• Hourly sync — фиксированный пик в начале часа

Что растёт ступенями (нелинейно)

• 5 cron jobs synci с Affilka/Alanbase — burst в :00
• Disabled Kafka consumers — реал-тайм недоступен (polling lag до 1ч)

Узкое место

Что сломается первым: manual_user_activity рост unbounded; hourly burst к Affilka API

Когда: ~100,000 DAU

Как обойти: Партицирование activity по месяцу; включить Kafka consumers; staggered cron windows

Минимальные ресурсы по DAU

Включает app + Postgres + Redis (single instance, +30% headroom). Для HA умножай app ×2-4, DB ×2.

Запросы к БД и Redis

Профиль: 2.0 q/HTTP-request (read: 1.5, write: 0.5), Redis: 0.2 ops/req, cache hit: 50%, avg query latency: 5 ms

Pool sizing: MAX(10, ceil((rd_QPS + wr_QPS) × avg_query_ms / 1000 × 1.5))

Особенности и риски

• Affilka/Alanbase синки — 5 hourly cron jobs. Spike нагрузки в начале каждого часа.
• Disabled Kafka consumers (4 шт) — реал-тайм атрибуция отключена → polling lag до 1 часа.
• manual_user_activity и affilka_users без партиционирования — рост неограничен.

Связи

См. граф зависимостей и Mermaid-диаграмму.

casino-referral-service

light Доля общего RPS: 1%

Что растёт линейно с DAU

• referrals — 1 row на новую регистрацию через линк
• Closure table до глубины 5 — линейно от регистраций

Что растёт ступенями (нелинейно)

• Monthly commission run (28-31 число, 23:59 UTC) — большой single-pass через всю closure table
• Concurrency 16 sync calls к stats может перегружать stats-сервис

Узкое место

Что сломается первым: Monthly commission run scaling — sync calls к stats не справляются при росте дерева

Когда: ~100,000 DAU

Как обойти: Bulk batch к stats; ограничить concurrency 8; разбить на chunks по 10k участников

Минимальные ресурсы по DAU

Включает app + Postgres + Redis (single instance, +30% headroom). Для HA умножай app ×2-4, DB ×2.

Запросы к БД и Redis

Профиль: 2.0 q/HTTP-request (read: 1.5, write: 0.5), Redis: 0.0 ops/req, cache hit: 0%, avg query latency: 5 ms

Pool sizing: MAX(10, ceil((rd_QPS + wr_QPS) × avg_query_ms / 1000 × 1.5))

Особенности и риски

• **Monthly commission run** (23:59 UTC, дни 28-31) — отдельный пик от steady-state.
• Closure table до глубины 5 — pagination обязателен на больших деревьях.
• Concurrency 16 sync calls к stats — может перегружать stats-service.
• Postgres 9 таблиц без TTL/partitioning.

Связи

См. граф зависимостей и Mermaid-диаграмму.

casino-notifications-service

medium (multi-channel fan-out) Доля общего RPS: 0.1%

Что растёт линейно с DAU

• notifications_log — линейно по событиям
• Provider API calls (FCM/Email/SMS) — линейно

Что растёт ступенями (нелинейно)

• Marketing campaigns — burst x10-100 за минуты
• Provider rate limits (SMS 100/sec, FCM 600k/min)

Узкое место

Что сломается первым: Fan-out amplification: 1 событие → O(users × channels) вызовов

Когда: ~50,000 DAU

Как обойти: Batch sending через Kafka producer; rate-limit per provider; в priority queue по типу

Минимальные ресурсы по DAU

Включает app + Postgres + Redis (single instance, +30% headroom). Для HA умножай app ×2-4, DB ×2.