Public API for Commentary

Business logic

The main purpose provide Commentary API.

Updated internal models get from listening kafka topics: commentary-api-events, commentary-api-events.

The main advantage is to not load and store a full offer in memory.

Has dependency from com.livescore.public-service-sdk: https://github.com/minelytix/spring-common-processor

OpenAPI specification

Internal Models

Handle two internal models: event, commentary. Internal models retrieved from kafka topics are written to mongodb collections and Internal cache.

Kafka

Listening two topics: commentary-api-events, commentary-api-commentaries.

Mongodb

Write resulting models into two collections: event, event-commentaries.

Startup

On startup data between range loaded from two mongodb collections (event, event-commentaries) is loaded into an internal cache.

Internal cache

Loaded from DB and stored in CaffeineCache. Used technology - Caffeine

CDN cache

The main purpose is to cache not finished and recently finished matches for 10s. The more time match was finished, it will be longer cached in CDN. Can be configured via properties:

cache-control:
  max-age:
    code-410: 5m
    commentary:
      notFinishedAndRecentlyFinished: 10s
      afterFinishTimeLadder:
        1h: 1m
        1d: 5m
        7d: 1d
        30d: 30d

VM instance configuration recommendations

CPU: 2 cores, RAM: 3 Gb, HDD: 20 Gb

Metrics

Grafana dashboard: 'Commentary prometheus monitoring'.

There are 3 types of metrics: GAUGE, COUNTER, TIMER (contains 2 dimensions: count and sum)

Custom metrics

model_updates_total (COUNTER)

total count of handled messages, received from kafka. Tags: model, operation

Predefined metrics

jetty.*: metrics show the state of jetty thread pool.

http_server_requests_seconds.* : displays how the api is used. Tags: exception, method, outcome, status, uri

spring_kafka_listener_seconds.* : displays information on kafka connection and consumption. Tags: exception, name, result

Test REST API Endpoints

Not present

Commentary

Endpoint to retrieve event commentaries by locale. Default locale - en.

Request example

GET /v1/api/app/event/1/comments HTTP/1.1
Content-Type: application/json;charset=UTF-8
Content-Length: 50
Host: example.com:8087

Response example

HTTP/1.1 200 OK
Content-Type: application/json
Cache-Control: max-age=100, public
Vary: Origin, Accept-Encoding
x-response-time: 2 ms
Content-Length: 757

{
    "Eid": "2438",
    "Lang": "en",
    "Com": [
        {
            "Min": 18,
            "Txt": "Facundo Mena wins the Game Point and the score is tied at 4-4 EN",
            "IT": 9
        }
    ]
}

Load testing scenarios

Testing of endpoint ` GET /v1/api/app/event/1/comments ` is need to be done with locale param in proportions: 60% for EN commentaries, 30% for NL, 10% withput locale param.

Scaling policy recommendations

If the api load is more than 70%, then we launch the second node

Adding new language

In commentary processor in config application.yml we need to add new language iso2Code in section 'languages.included' (with comma splitter without spaces). For example if we want to add Ukrainian language to existed languages in config must be:

languages:
 included: en,nl,ua