Для шахматного сервиса с 1 млн пользователей и 50k DAU, где игрок играет около 5 игр в день, архитектуру стоит строить с учетом масштабируемости, отказоустойчивости и низкой задержки.

Основные компоненты:

Frontend — веб и мобильные клиенты.
API Gateway — маршрутизация запросов, аутентификация.
Сервис профилей — хранение информации о пользователях (реляционная БД, например PostgreSQL).
Матчмейкинг — сервис, который подбирает соперников по рейтингу и активности. Можно реализовать с использованием очередей и кэширования (Redis).
Игровой сервис — управление состоянием партий, ходами, таймингом. Для хранения состояния игр можно использовать быстрые базы данных (например, Redis для текущих партий) и долговременное хранение в реляционной БД.
Ачивки и статистика — отдельный сервис с возможностью аналитики.
Система уведомлений — push-уведомления, email.

Технологии и подходы:

Использовать микросервисную архитектуру для независимого масштабирования компонентов.
Горизонтальное масштабирование игровых сервисов и матчмейкинга.
Кэширование часто запрашиваемых данных (профили, рейтинги) в Redis.
Использовать WebSocket или gRPC для реального времени в играх.
Хранить логи и статистику в аналитических базах (например, ClickHouse).

Пример упрощенной архитектуры:

[Frontend] <-> [API Gateway] <-> [Profile Service (PostgreSQL)]
                                |-> [Matchmaking Service (Redis + Go)]
                                |-> [Game Service (Redis + PostgreSQL)]
                                |-> [Achievements Service]
                                |-> [Notification Service]

Такой подход обеспечит масштабируемость и отзывчивость сервиса при высокой нагрузке.