Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

З

Page Properties


Status
Status
colourYellow
titleIn progress
StakeholdersPlatform team members, interested Tech Leads
Outcome


Due date


Owner



This page defines the terms and requirements for FOLIO back-end modules related to the high availability.

Definitions

  • Stateless - In the scope of the FOLIO back-end modules it means that neither session information nor business flow-related data is retained in the memory or local file system or other persistence mechanism managed by the a particular module instance. Relevant data is sent to the module by the client in such a way that every HTTP request can be understood and handled in isolation without context information from previous or simultaneous requests. There is nothing that leads to the dependence of one HTTP request on another except the content of the database or another shared persistent storage available to all instances of the module. This does not apply to any sort of soft data (caches) that can be easily read from the persistent storage.
  • Horizontal scaling - it means that adding more instances of a particular module to (or removing redundant instances from) the deployed FOLIO platform does not affect, break, or disrupt existing business flows or user sessions in any way.
  • High availability (HA) refers to the ability of a system to operate reliably, without unplanned interruption, at an agreed-upon level of service. This is a characteristic of how a system is deployed and operated. To allow for HA deployment, Folio incorporates design elements that allow hosting operations to use horizontal scaling, redundancy, and automated failovers.

Requirements for the FOLIO back-end modules

All back-end modules must follow the stateless requirement as it is described in the “Definitions” section. It will guarantee that guarantees horizontal scaling and, therefore, high availability, as it is described in the “Definitions” sections, can be supported without issues.

Special cases

  • If a business flow requires file uploading functionality or any other interactions with files or any other kinds of persistent objects the acceptable solution for that must be worked out and discussed further and the results must be reflected on this page.
    • Preliminary it is supposed to use MinIO to utilize S3-like storage types
  • If a business flow requires preserving some intermediate state between HTTP requests or any other "session-like" features the database , a database or shared persistence storage (S3 or MinIO Server) must be used as the storage. Developers . In addition, developers must take care of freeing up resources when they are no longer needed (deleting obsolete rows from tables or removing objects from storage, or providing requirements for eviction policies for storage).
    • A good alternative
  • here
    • could be introducing a distributed in-memory storage to the FOLIO platform to support and speed up such cases.