Public API for Favorites
|
See Release Notes. |
Business logic
The main purpose of this service is to replicate the existing functionality of MYM and MYT endpoints in terms of new 'Favourite service'. This will decrease the load on the 'Master Service'.
New component Favorites API will provide information about matches(events) and teams(participants) for mobile and web LS clients.
_The main advantage is to load and store a full offer in memory
The client response is created only from in-memory data, it allow to avoid slow database queries and minimises response times. Responses are created in special serializer classes
Request restrictions:
data:
request:
max-teams-per-request: 50
max-events-per-request: 200
eventsForSpecificTeam:
teamMaxEvent: 3
matchesRemainTime: 12h
Public endpoints
My matches
/v1/api/app/mym/[sport]?eventIds=[eventId]&teamIds=[teamId]
Returns information of favorite matches. If present one event, returns one event information.
What events will return, if parameter 'eventIds' has more events, that parameter 'limit'? Before limitation all requested events are sorted by their start times (earlier on top). So 'limit' parameter will limit the latest events by startTime. But on client’s side "old" events are filtered (that have finished later that 48h from now). So, user cannot see events, that older than 48h. Note: When user starts scrolling results, a new request will be sent with increased parameter 'offset', so he will see next page with events, that were limited before.
If present one team, returns three (configured by teamMaxEvent property in application.yml) events and if present one event with team, returns four event.
What events are selected by teamId ?
-
Get all events by teamId (this step optimized in method TeamEventAggregator.computeAndCachePotentiallyTeamEventIds)
-
Exclude eventIds received from request
-
Filter events by status (NOT_STARTED, IN_PROGRESS, INTERRUPTED, FINISHED)
-
Filter by TimeRange: now < event.scheduledStartDateTime + data.eventsForSpecificTeam.matchesRemainTime (48h)
-
Sort events: by ScheduledStartDateTimeUTC, ParticipantNames (if ScheduledStartDateTimes are equels)
-
Limit event count: data.eventsForSpecificTeam.teamMaxEvent (3)
-
Present stage sorted by positionScores and if they has the same positionsScores then thats sorts by positionTeams
-
In the stages scope, we sorts by StartDateTime or, if StartDateTime matches, then sorts by "name"
My team
/v1/api/app/myt/[sport]?teamIds=[teamId]
Return information of favorite teams
sport: "soccer", "tennis", "hockey", "basketball", "cricket", "horses";
Internal models
Handle next internal models: participant, stage, season, event, region, categorise. Internal models retrieved from kafka topics are written to Internal cache.
- Kafka
-
Listening six topics: 'favorites-api-events', 'favorites-api-participants', 'favorites-api-stages', 'favorites-api-seasons', 'favorites-api-regions', 'favorites-api-categories'.
- Cache
-
Recording the resulting models in six storage caches: participant, stage, season, event, region, categories.
Startup
On application startup firstly we try to load all records from mongodb and save received messages from next kafka topics ('favorites-api-events', 'favorites-api-participants', 'favorites-api-stages', 'favorites-api-seasons', 'favorites-api-regions', 'favorites-api-categories') to cache
Internal cache
Loaded from DB (MongoDB) and stored in ConcurrentMap. It’s thread-safety map with high throughput under high concurrency.
CDN cache
Cache lifetime is set in application config file 'cache-control:':
mym-max-age-seconds: 10 myt-max-age-seconds: 3600
Time presented in seconds.
Metrics
Grafana dashboard: 'Favorites prometheus monitoring'.
There are 3 types of metrics: GAUGE, COUNTER, TIMER (contains 2 dimensions: count and sum)