Тестовое на Junior+/Middle-: сделал игру. Кажется, немного перестарался или нет?

Задание было довольно небольшим — симулятор доставки на луноходах. Формально можно было сделать frontend + mock-данные. Я решил подойти к нему как к маленькому реальному продукту:

Игра (React+Phaser) ──REST+WS──► game-api (FastAPI) ──► SQLite │ игровые события ▼ Event API ──► Redpanda ──► Event Processor ──► ClickHouse ──► Analytics API/дашборд

Что в итоге сделал: — game-api — источник истины: клиент отправляет действие, а вес, батарея, риск и результат миссии проверяет сервер; — WebSocket для обновления игрового состояния; — Redpanda для отделения игры от аналитики и сохранения порядка событий игрока; — batch-запись в ClickHouse + at-least-once: offset коммитится только после успешного INSERT; — отдельная аналитика: воронка, success/fail, эффективность роверов, маршруты, причины отказов; — Docker Compose + unit/E2E тесты.

При этом специально оставил и ограничения: нет дедупликации событий, клиентская телеметрия best-effort, нет auth, а SQLite при реальной многопользовательской нагрузке я бы заменил на PostgreSQL.

И вот здесь мне реально интересно мнение более опытных разработчиков.

Есть ли вообще смысл настолько заморачиваться с тестовыми? Смотрят ли работодатели на такие детали архитектуры или большая часть этой работы остаётся незамеченной? Насколько сама архитектура адекватная? В реальных игровых проектах телеметрию и аналитику строят похожим образом или я где-то ушёл в overengineering?

И если кто-то работает с backend / event-driven системами / gamedev — буду очень рад ревью. Где решение хорошее, где спорное, а где я просто перемудрил?

Код: https://github.com/Shira-Artem/moon-courier-crisis Сейчас ищу backend / fullstack позицию 🙂