megazordpobeda/datarush

Purpose and entry points

DataRush is a containerized platform for data-analysis competitions: users authenticate, join competitions, submit task solutions, receive asynchronous checking results, and view reviews, achievements, and standings. Docker Compose is the deployment entry point: compose.yaml. Public routes are served through infrastructure/nginx/nginx.conf; primary interfaces are the React UI, Django API/admin, Grafana, and learning documentation.

Edge and client application

Nginx fronts the stack and routes the browser to the frontend and backend-facing services. The React/Vite/TypeScript SPA owns user-facing competition flows, including session task answering and submission state:

• services/frontend/src/main.tsx

• services/frontend/src/App.tsx

• services/frontend/src/pages/CompetitionSession/index.tsx

Its API boundary is centralized under services/frontend/src/shared/api/, with authentication/session data managed separately from page widgets.

Backend API and domain core

The backend is Django with Django Ninja REST endpoints. Django bootstraps ASGI/WSGI, settings, URL routing, and Celery:

• services/backend/config/settings.py

• services/backend/config/urls.py

• services/backend/api/v1/router.py

API resources map to domain apps rather than placing persistence logic in the frontend: competition, task, team, user, review, and achievement endpoints are under services/backend/api/v1/; corresponding models and lifecycle signals live under services/backend/apps/.

Competition lifecycle and persistence

PostgreSQL is the system of record for users, teams, competitions, tasks, submissions, reviews, and achievement state. Competition state changes and review/user signals express cross-domain lifecycle effects:

• services/backend/apps/competition/models.py

• services/backend/apps/task/models.py

• services/backend/apps/review/models.py

Django admin provides operational management and a competition leaderboard template. Database initialization/data generation is performed through backend scripts and management commands, rather than by the client.

Submission and asynchronous checking

A solution submitted from the competition-session UI reaches backend task APIs, is queued through Celery, then sent to the checker integration. Task worker orchestration and checker health boundary are located at:

• services/backend/apps/task/tasks.py

• services/backend/config/celery.py

• services/backend/integrations/checker/healthcheck.py

Redis is the Celery broker/result-supporting runtime, configured as infrastructure alongside PostgreSQL. This separates request handling from potentially slow or unsafe user-code execution.

Checker isolation boundary

The checker is an independent FastAPI service with an /execute endpoint. It runs user submissions in disposable Docker containers with fixed CPU, memory, dependency, and execution-time limits; it is the security boundary for arbitrary code:

• services/checker/main.py

• services/checker/config.py

• services/checker/Dockerfile.checker

The backend/checker contract is service-to-service and should remain independent of frontend types or UI workflow.

Operations, observability, and supporting services

Compose assembles backend, frontend, checker, PostgreSQL, Redis, and supporting services. MinIO provides object-storage infrastructure; documentation is a separate Docusaurus service. Prometheus gathers metrics, exporters expose Postgres/Redis/Celery metrics, and Grafana provisions dashboards:

• compose.yaml

• infrastructure/prometheus/prometheus.yaml

• infrastructure/grafana/provisioning/dashboards/providers.yaml

Operational ingress, monitoring, and admin tools are infrastructure concerns, not backend domain dependencies.