RNA-Bee Architecture

INSERT: RNA-Bee Hero / Architecture Pattern

RNA-Bee Architecture — separating the web platform from scientific computation

RNA-Bee is built as a containerized multi-service application. The architecture deliberately separates the public website, API, persistence, asynchronous workloads and scientific computation instead of placing everything inside a single application.

The goal is not maximum complexity. It is clear responsibility: each component should do one job well and remain replaceable as the project evolves.

The architecture at a glance

The application is divided into two main layers: a public web layer and a computational backend.

WordPress handles the public website and block-based user interface.
Django REST Framework provides the application API and coordinates simulation logic.
PostgreSQL stores application and scientific experiment data.
Redis acts as the message broker for asynchronous jobs.
Celery workers execute computational tasks outside normal web requests.
ViennaRNA and other scientific tools provide the actual RNA algorithms.
MariaDB stores the WordPress application data.
Apache provides the public HTTPS entry point and routes requests to the correct service.

One public endpoint, two applications

From the browser, RNA-Bee looks like a single website. Internally, however, normal website requests and API requests are handled by different applications.

https://rna-bee.nathabee.de/
        |
        +---- /       → WordPress
        |
        +---- /api/   → Django REST API

Apache sits in front of the Docker services and acts as the reverse proxy. This keeps the individual containers private while exposing only the routes that visitors actually need.

The routing decision is simple but important: WordPress remains responsible for pages, navigation and interaction, while scientific requests are directed to the Python backend.

INSERT: Reverse Proxy / Request Flow Diagram

Why WordPress and Django?

Using WordPress and Django together may initially look unusual, but the two systems solve very different problems.

WordPress

Pages and navigation
Gutenberg blocks
Content and documentation
Interactive project interface
Theme and visual presentation

Django

Scientific application logic
REST API
Experiment models
Simulation orchestration
Integration with Python scientific libraries

The separation keeps WordPress out of scientific computation and avoids forcing the Django backend to become a content-management system.

Asynchronous computation with Celery and Redis

Some RNA calculations may finish quickly, while others can involve many sequences, generations or repeated folding operations. Those workloads should not keep a browser request open until the entire simulation finishes.

RNA-Bee therefore separates web requests from computational jobs.

User starts experiment
        |
        v
Django API
        |
        v
Create job
        |
        v
Redis queue
        |
        v
Celery worker
        |
        v
RNA computation
        |
        v
Store result

Django can accept an experiment, validate it and create a job. A Celery worker then performs the actual computation independently. The frontend can query the API for progress and results without tying the lifetime of the experiment to a single HTTP request.

INSERT: Celery Job Flow Diagram

Two databases for two responsibilities

RNA-Bee deliberately does not force WordPress and the scientific backend into the same database.

MariaDB

MariaDB belongs to WordPress and stores normal CMS data such as pages, configuration, users and site content.

PostgreSQL

PostgreSQL belongs to Django and is intended for simulation runs, experiment definitions, sequences, generations, computed properties and other application-specific data.

This boundary prevents scientific domain models from becoming dependent on WordPress tables and makes the Python application easier to test, migrate and evolve independently.

Keeping the scientific engines replaceable

The computational layer should not be tightly coupled to one RNA library. RNA-Bee is designed so that the simulation engine can ask for operations such as folding or scoring through a defined application interface.

Simulation Engine
        |
        v
RNA prediction interface
        |
        +---- ViennaRNA adapter
        |
        +---- RNAstructure adapter
        |
        +---- future engines

This adapter-based approach allows the project to begin with ViennaRNA while leaving room for comparison, validation or additional scientific engines later.

The simulation model should therefore understand concepts such as sequence, structure, energy and fitness, but it should not need to know the command-line details or API conventions of a particular external library.

Docker as the application boundary

RNA-Bee uses Docker Compose to describe the complete runtime environment. Each major responsibility runs in its own service while persistent data is stored outside the disposable container filesystem.

WordPress
WordPress MariaDB
Django API
Celery worker
PostgreSQL
Redis

This makes the application reproducible: the same project definition can be used for development, testing and deployment without manually rebuilding the entire server environment.

INSERT: Docker Services / Networks Diagram

Public services and private services

Not every container should be reachable from the internet.

Only the public web interfaces need host-level access. Databases, Redis and background workers remain internal to the Docker environment and communicate over private networks.

Public through Apache: WordPress
Public through Apache: Django API
Private: PostgreSQL
Private: MariaDB
Private: Redis
Private: Celery workers

This reduces the exposed attack surface and keeps infrastructure components behind the application boundary.

Persistence without treating containers as servers

Containers are replaceable. Data is not.

RNA-Bee therefore keeps persistent state in dedicated Docker volumes rather than relying on the writable filesystem of a particular container instance.

WordPress database data
WordPress uploads and runtime files
PostgreSQL application data
Redis persistence where required
Simulation-generated files and results

A service can therefore be rebuilt or upgraded without implying that its application data should disappear with it.

Design principles behind the architecture

Separation of concerns — presentation, API, data and computation remain distinct.
Replaceability — individual scientific engines and infrastructure components should be exchangeable.
Reproducibility — the environment is described as code rather than reconstructed manually.
Asynchronous by design — expensive simulation work does not belong in browser request lifecycles.
Minimal exposure — databases and infrastructure services remain private.
Independent evolution — the WordPress interface and Python scientific backend can change at different speeds.

The architecture is intentionally modular: the web interface asks for scientific work, but it does not perform the science itself.

Where the architecture goes next

The infrastructure is only the foundation. The next major architectural work happens inside the scientific domain: defining sequences and experiments, implementing folding adapters, representing mutation and fitness, and designing evolutionary runs that remain reproducible.

That is the subject of the next article in the RNA-Bee series.

INSERT: Link / Button to “Building the RNA Simulation Engine”

The RNA-Bee series

Introducing RNA-Bee — the project, RNA folding, evolution and its goals
RNA-Bee Architecture — system architecture and technical decisions
Building the RNA Simulation Engine — ViennaRNA, RNAstructure, mutation, folding, fitness and evolution
Building the RNA-Bee Web Platform — Docker, Django REST, Celery, Redis and WordPress integration

Project links

Open RNA-Bee

View source on GitHub

Nathabee Creations