Skip to main content

Master-Slave server architecture

Concept​

The decentralized master-slave architecture means the application does not run on a single central application server but is distributed across multiple branch or regional sub-servers ("slaves"). These sub-servers connect to a central server (the "master"). The central server stores system configurations, which the sub-servers mirror into their local databases. The mirroring process is unidirectional, and the entire system can only be administered through the central server.

The central server also collects statistical data from the sub-servers, providing a complete statistical dataset for the entire system. This mirroring of statistics is also unidirectional; data flows only toward the central server (opposite the direction of configuration mirroring). In case of a network failure (if the connection between a sub-server and the central server is interrupted), operations continue without issues (e.g., tickets can be requested and issued), but administrative tasks can only resume after the connection to the central server is restored.

Apart from database mirroring, it is also necessary to mirror the "media" directory, which stores advertisements and other media content. This is required for two reasons:

Images, videos, and profiles for media players need to be copied to the sub-servers. Advertisements displayed on ticket issuers and tickets are distributed to branch/regional servers this way. Both master and slave servers can be set up as clustered server groups.

Architecture

Advantages​

  • The branches can operate independently in case of slow or unreliable network connections.
  • Low-resource machines are sufficient for slave servers.
  • A slave server can run on the ticket issuer itself to handle a single branch.

Disadvantages​

  • Configuration changes are delayed before being applied to slave servers.
  • Statistical data is only visible at the central server with delays.
  • If the Master server connection is unavailable, branch settings (e.g., matrix) cannot be modified.
  • More complex installation and maintenance, as a slave server must be installed in each branch.

Installation​

The master server has to be installed with the installer file and no further configuration is necessary. The slave server can be installed with the same installer, but after installation the application.xml file has to be edited in order to disable the "Master processes" and enable "Slave processes" for the required functionality:

YAML file