Delta Feed
Data Elements
Every event consists of 4 data elements. eventInfo - basic information about the event. markets - contains data about markets, selection and odds values. scoreboard - contains data about periods and score. betCancellations - contains data about the time period in which bets placed on specific markets should be cancelled.
Every data element has a dedicated delta type that is used to send updates for this specific element. Two exceptions are eventSnapshotDelta (type6), which contains all data elements, and eventStatusChangedDelta (type 1), which is used to update status and tradingStatus that are located inside eventInfo.
Data Storage Recommendations
Recommended approach of storing data for events is following. eventInfo should be stored in a document database like MongoDB. markets, scoreboard, betCancellation data is stored in a cache like Redis. This allows for time critical data of markets/odds to be processed and forwarded to frontend as fast as it is possible.
Establishing Connection
After receiving credentials from TIS, the next step is to establish connection with Odds88 websocket delta feed. We recommend doing initial connection with revision = 0 to get messages for all active events. After that you should connect with revision = version from latest delta received.
Storing Data
Subscribing with revision = 0 will generate snapshots (type 6 delta) for all events active in a Odds88 system. This type of delta contains full data about an event and includes all 4 data elements. If an event doesn’t exist in the your database, it should be created. If an event exists all data elements that changed should be updated.
Upon receiving delta of type 2 a new event should be created in your DB. If an event already exists, changed fields should be updated. Deltas of type 2 and 6 are the only two deltas that should create new events in your database.
Next step is to process every other delta type that contains only updates for already existing events and update changed fields/properties in the database/cache for further use in your system/frontend solution. Structure of all delta types can be checked in swagger.
Events can have from 0 to many markets.
Markets can have from 1 to many selections.
After message processing is implemented, you can populate your database by connecting to feed with 0 revision. In case of reconnection it should happen with revision = version from latest delta processed. Existing data should be enough to create frontend views of sports, leagues and events.
To process messages it is required to use a multithreaded solution. Number of messages and their size can be significant during peak hours for a single threaded solution to handle the volume.
It is recommended to use MongoDB + Redis, for quick and reliable forwarding of data to frontend.
Last updated