Hi everyone,
I’m working on the backend for a gaming community website, and I’m at the point where I need to decide how to structure a couple of related APIs before they grow too much.
The site is centered around GeometrryDash and includes player profiles, community-created content, and leaderboards based on different criteria (most completed levels, user ratings, etc.).
Right now I have a single backend service exposing endpoints such as:
GET /players/{id}
GET /players/{id}/stats
GET /leaderboards/global
GET /leaderboards/weekly
As more features are being added, the profile endpoints are starting to include data that’s also needed by the leaderboard endpoints (rank, completion stats, badges, recent activity). I’m debating whether to:
- Keep everything behind one service and optimize with caching.
- Split the leaderboard functionality into its own service now.
- Keep a single service but introduce separate internal modules and postpone any service split until traffic actually justifies it.
One thing I’m trying to avoid is duplicating queries or ending up with APIs that become tightly coupled as new features are added.
For those of you running Kong in production, at what point do you usually decide that a feature deserves its own upstream service instead of remaining part of the existing API?
Also, if you have separate profile and leaderboard services, do you aggregate those responses at the gateway layer, or do you leave that responsibility to the client application?
I’d be interested to hear how others have approached a similar architecture before I lock in this design.
Thanks!