# System introduction

We are the provider of B2B online entertainment platform provider.

We provide a complete set of websites necessary for a brand to operate their online entertainment platform, or allowing owner to operate online entertainment to rent.

## 1. System Structure

1. Portal.Web (Front-end)
Online gaming platform, members to login, play games, deposit, withdrawal, check history.

Developed in ***Vue***
3. PortalApi (Back-end)
The backend service called by Portal.Web, including all front-end APIs for:
Login/Logout
Create Account
Launch game
Deposit
Withdraw
Check Betting history
etc..

5. **Master**
Backoffice used by the owner of the online platform. The owner manages the website of the platform, including but not limited to reviewing member withdrawal, creating bonus, checking member list, etc..

7. **Agent**
Backoffice used by the people who can bring in new members called agent. Agent can use this backoffice to check their earnings brought in by their downlines and members.

9. Admin
Backoffice used by us (the platform provider) to manage the website of Brands who rent from us including permissions.
RD team is able to gain access to brand websites to perform checking through this website.

11. RobotCenter
Responsible for grabbing all the bet record placed on our platfrom from all vendors.

13. Robot
Responsible for inserting all the bet record captured by RobotCenter into its respective brand.

15. ApiCenter
Utility purpose, to handle Third-party login verification.

17. Api
For all other usage, such as seamless wallet

19. ThirdPartyJump
To support deposit flow jump to third-party payment provider, and after deposit is done, to receive callback from third-party payment provider

21. GameJump
Is only required for certain vendor, and is usually used additionally when entering the game

## 2. Platform AP Classification

**There will only be one set for all platforms**
* ONE series
* Admin
* ApiCenter
* RobotCenter
* GameJump

**Each brand will have a set**
* SITE series
* Agent
* APIs
* Robot
* ThirdPartyJump
* Master
* Portal.API
* Portal.Web

## 3. DB Schema

One server is responsible for writing
Another server will be only able to read (ReadOnly) - for reporting purpose, or retrieving data

During development, it is necessary to verify when to use ReadOnly and when not to according to the situation.

Classified as CenterDB, BalanceDB, SiteDB

| Center DB | Shared DB, only one set, shared by all brands |
| -------- | -------- |
| CasinoConnectionCenter | SiteDB connection information |
| CasinoStructuralDefinition | Game management/website information, game BB upline settings for each brand |
| CasinoDataCenter | Shared data, EX. Game/Front-end display information |
| *CasinoConfigCenter* | Shared setting data, EX. Game/Front-end display information/Third-party payment information |
| CasinoConfigCenterBalance | BalanceDB connection information |
| CasinoRawCenter | Bet record data |

| BalanceDB | Reconciliation DB, only one set, shared by all brands |
| -------- | -------- |
| CasinoBalanceCenter | Reconciliation DB, multiple tables are created based on game |

| SiteDB | Brand platform DB, one set for each brand |
| -------- | -------- |
| *CasinoCash.KD001* | DEV |
| CasinoCash.OK003 | STAGE |
| CasinoCash.KR00X | PROD |
| CasinoCash.EX001 | Sample DB used for demo site. Whenever there are DB changes, this DB also need to be updated |

| Statistic Data | |
| -------- | -------- |
| CasinoStatistics | Before going online, temporarily added to assess VISITOR access speed to web resources. This is independent to another SERVER because the amount of data might be too large |

## 4. Development Environment
The relationship between **each brand** and **PortalApi** is **many-to-one**

Stage(OK003) also uses this method which is easier to verify and reduces the cost of adding servers

## 5. Official Environment
The relationship between **Portal.Web** and **Portal.Api** is **one-to-one**