---
# System prepended metadata

title: System introduction

---

# 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
![](https://i.imgur.com/jK18Dwy.jpg)

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**