Architecture

This document explains the design details and goals for the architecture of LibreTime. It describes the result of a discussion that happened on Github.

Previous architecture

The previous architecture of LibreTime (based on AirTime) was missing a proper separation of concerns. It was build around a legacy MVC app written in PHP, and services in Python to accomplish specific tasks.

New architecture

Below is the new architecture goal of LibreTime, with a proper separation of concerns.

The LibreTime architecture is split into 2 main monolithic blocks Create the schedule and Play the schedule. Both blocks must be able to scale horizontally.

note

A microservice architecture was rejected as it will not fix or improve any aspect of LibreTime.

warning

This document tries to focus on creating and playing a schedule, it does not consider features such as monitoring, logging or archiving.

Create the schedule

This block contains the following components:

• a web API,
• a worker to run background tasks,
• a message API to communicate with the Play the schedule block, and other services,
• a web app to interface with the users.

The web API, the worker and the message API rely on the Django framework to handle database, message queue and storage access.

Play the schedule

Since the Play the schedule has its own requirements in terms of logic and uptime, it is handled separately from the Create the schedule block. This block needs to be able to be duplicated in a high availability context.

This block contains the following components:

• a Playout app that communicates with the Play the schedule block to gather the schedule,
• a Liquisoap app that plays and mixes the scheduled items, and dispatch them to the delivery services,
• an Icecast server that delivers a legacy audio stream to the public,
• a HLS stream that delivers a modern audio stream to the public.

One setup per radio station

LibreTime is not meant to be used in a multi-tenant architecture, and an entire LibreTime installation should be dedicated to a single radio station. Previous SAAS or multi-tenant features from Airtime should be deprecated or removed.

Separation of concerns

The Create the schedule block must only prepare a schedule, and the Play the schedule must only play that schedule. A strong separation of concerns is required between the 2 blocks to allow the Play the schedule block to meet its uptime requirements while not depending on the Create the schedule in case of a failure. Development will be simplified if both blocks share a single and properly defined protocol.