Ballogy Platform Architecture
Four services, one identity.
The backend architecture behind Ballogy, an athlete training platform: four independently deployed services covering identity, training (drills, assessments and shot-tracking) and notifications, plus the layer that connects athletes to a generative AI coaching assistant.
- Attribution
- Founder Experience
- Period
- 2024 – present
- Category
- Backend Systems
- Source
- Proprietary
4 services
One identity, independent deploys
01The challenge
Four services had to trust a single identity without re-authenticating on every call. Background processing could not be allowed to starve the API. And athletes needed access to an AI coaching assistant with fair, per-profile usage limits and relevant context.
02The solution
A JWT trust model anchored in one identity service, API and background workers split into separate Kubernetes deployments, and a bridging layer that owns quota, chat history and context assembly around an external AI agent.
03Key features
- 01
Identity, authentication and profiles centralised in one Django service
- 02
FastAPI services for drills, assessments and shot-tracking
- 03
Push and in-app notification service
- 04
Freemium AI-coaching quota scoped per profile and per sport
- 05
Chat session and history APIs for the mobile app
- 06
Independent delivery per service: Bitbucket → ECR → kubectl on AWS EKS
04Engineering approach
How it's built.
- Django
- FastAPI
- Celery
- Redis
- PostgreSQL
- MongoDB
- JWT
- Kubernetes
- AWS EKS
- 01
Identity sits in one service: ballogy-users issues the JWT and the other three services decode it with shared-secret middleware, removing a callback on every request.
- 02
API and background work never share a pod: Celery and django-q workers and beat schedulers run as separate Kubernetes deployments from the web API.
- 03
A production database connection-pool exhaustion incident on the training service was resolved by splitting API, worker and beat processes into separate deployments with tuned pool sizes — not by adding hardware.
- 04
The platform doesn't generate AI responses itself. It owns identity, quota, history and context assembly, and bridges to a separate generative AI service over HTTP.
- 05
Coaching quota is scoped per profile and per sport rather than pooled across an account — fixing a real bug where limits leaked across profiles.
- 06
Context sent to the AI agent is capped at the last ten days of reports, so grounding stays relevant without an unbounded payload.
05Project gallery
Inside the system.
Architecture views drawn from the project's documented design.
System views · architecture from verified project notes
Four services, one identity.
Independently deployed services trust a single identity provider instead of re-authenticating on every call, with background work isolated into its own pods.
- 0102
ballogy-users
Django — identity, auth & profiles
- 0203
JWT middleware
Shared secret, no callback per request
- 0304
training / tests
FastAPI — drills, assessments, shot-tracking
- 0405
notification
Django — push and in-app notifications
- 0506
Celery · Redis · django-q
Workers in separate pods from the API
- 06
AWS EKS
Bitbucket → ECR → kubectl, per service
Key design decisions
- One service issues identity; the rest verify tokens locally.
- API, workers and schedulers run as separate Kubernetes deployments.
- A pool-exhaustion incident was fixed by process separation and tuned pool sizes.
06Outcome
What it delivered.
A platform where each service deploys on its own, authentication doesn't cost a network call per request, and background load stays isolated from the API.
- Independently deployed services sharing one identity
- 4
As published in the founder's portfolio. No figures on this page are estimates or projections.
07Project attribution
Founder ExperienceBackend and AI-integration engineering led by our founder as Senior Software Engineer (Backend & AI Architecture) at Kinetic Intelligence, Dubai, UAE. Shown as founder experience — it is not a Code Velocity client engagement. The system is proprietary, so no source code or screenshots are published.