Camunda Platform Reference

Architecture
Executive Summary JAVA APPLICATIONS

Camunda Platform offers significant flexibility

with regards to architecture, deployment
options, programming languages and supported
infrastructure. This document covers Camunda RUNTIME CONTAINER PROCESS ENGINE
(APPLICATION SERVER) (CONTAINER SERVICE)
process engine implementation options, supported
infrastructure specifications, hardware sizing and
recommended database management systems. Standalone (Remote) Process Engine
Server
Process Engine Implementation
Options The process engine is provided as a network service.
Different applications can interact with it through
The flexibility of Camunda Platform is demonstrated remote communication, usually via the built-in
with this sampling of implementation options. REST API. Other channels such as SOAP or JMS are
­Typically, initial forays with Camunda use Spring Boot possible but need to be implemented by users.
or a shared container though Docker is b ­ ecoming
a more popular option. All options work equally REMOTE APPLICATIONS
well and as a result there is no one recommended
­implementation option. And you don’t have to stick
to one approach for all use cases. Given our l­ icensing
flexibility you can create as many environments as
STANDALONE
needed in any topology required. Only execution PROCESS ENGINE
metrics in your production environments count SERVER

­toward your license. No need to count CPUs or

servers. ­Development and QA environments are Cluster Model
unlimited.
To provide scale-up and fail-over capabilities, the
Embedded Process Engine (Microservice) process engine can be distributed to different
nodes in a cluster. Each process engine instance
The process engine is added as an application library then connects to a shared database. The individual
to a custom application. This way, the process engine process engine instances do not maintain session
can easily be turned on or off with the application state across transactions. Whenever the process
lifecycle. It is possible to run multiple embedded engine runs a transaction, the complete state is
process engines on top of the same shared database. flushed out to the shared database. This makes it
possible to route subsequent requests which do work
Shared, Container-Managed Process in the same process instance to different cluster
Engine nodes. This model is very simple and easy to manage.

The process engine is started inside the runtime APPLICATIONS

container (servlet container, application server),

provided as a container service and can be shared by CLUSTERED
all applications deployed inside the container. PROCESS
ENGINE

SHARED DATABASE

camunda.com OCTOBER 2021

 YOUR
Multi-Tenancy Models APPLICATION
DOCKER IMAGE

To serve multiple, independent parties with one TOMCAT

Camunda installation, the process engine supports WEB APPS REST

the following multi-tenancy models: CAMUNDA

• Table-level data separation by using different DATA SOURCE

database schemas or databases

• Row-level data separation by using a tenant
marker

Users should choose the model which fits their data DATABASE
separation needs. Camunda’s APIs provide access to
processes and related data specific to each tenant.

Supported Infrastructure Options Hardware and Sizing

Camunda Platform can run in any Java-runnable Process Engine
environment. As of version 7.16, Camunda Platform is
supported with our QA infrastructure in the following High Availability: It is recommended to run the
environments. process engine on at least two nodes to ensure high
availability. The nodes do not have to form a proper
Containers for Runtime Components cluster in terms of an application server cluster. It is
sufficient to connect two identical nodes to the same
Application-Embedded Process Engine: database schema.

• All Java application servers Virtualization: Camunda can be run on virtualized

• Camunda Spring Boot Starter: embedded Tomcat systems. This does not impact licensing because
• Camunda Engine Quarkus Extension licenses are not bound to CPU cores.

Container-Managed Process Engine and Web Resource requirements are based on expected
Applications: workloads. Listed below are Camunda’s
recommendations:
• Apache Tomcat 9.0
• JBoss EAP 7.0 / 7.1 / 7.2 / 7.3 / 7.4 Small Supports most use cases, typical server
• Wildfly Application Server 13.0 / 14.0 / 15.0 / configuration 1-2 CPU cores, 1-8 GB
16.0 / 17.0 / 18.0 / 19.0 / 20.0 / 21.0 / 22.0 / 23.0 RAM
• IBM WebSphere Application Server 8.5 / 9.0
Medium Higher volume environments averaging
(­Enterprise Edition only) more than 100 instances per second,
• Oracle WebLogic 12c (12R2) (Enterprise Edition typical server configuration 2-4 CPU
only) cores, 4-16 GB RAM

Large Extreme volume environment or one

Docker where CPU intensive code has been
deployed, typical server configuration
Pre-built Docker images of Camunda Platform — 4-64 CPU, 16-128 GB RAM
Enterprise Edition are available via registry.
camunda.cloud. Packaging the components shown
below, the Camunda Docker images are suitable for
the remote process engine architecture.

camunda.com OCTOBER 2021

A cluster of two small servers should suffice most Database Clustering and Replication
common projects. Larger configurations should be
considered when: Clustered or replicated databases are supported
when:
• The system needs to handle more than 100
process instances/second • The communication between Camunda
• The system needs to support CPU intense Platform and the database cluster matches the
delegation code or locally running services like corresponding non-clustered, non-replicated
data aggregation or transformation configuration
• The code or deployment call for unique • The cluster configuration guarantees the behavior
requirements of READ-COMMITTED isolation level

Load testing of deployed applications is the best Galera Cluster for MariaDB is supported with specific
approach for determining hardware sizing. configuration settings and some known limitations.

In addition, depending on the container the system Java

requires approximately 500 MB to 1 GB of disk space.
Camunda recommends at least 2 GB of storage Java runtimes are supported as long as they are
in order to store enough logs for troubleshooting supported by the application server or container.
purposes.
Database Sizing
Database Management Systems
The amount of space required on the database
To ensure availability, databases should be clustered depends on
and running on at least two nodes at any given time.
1. History Level: Turning off history saves a huge
Recommended Database types amount of tablespace as you only keep current
runtime data in the database. However, it is
A large variety of database management systems advised to keep it to “FULL” to get the maximum
(DBMS) are supported. Camunda recommends audit logging from the process engine.
Oracle or PostgreSQL for production and H2 for
development. 2. Process Variables must be written to the
• MySQL 5.7 / 8.0 database (in a serialized form such as JSON).
• MariaDB 10.2 / 10.3 With the history level “FULL,” an entry is inserted
• Oracle 12c / 19c into history tables every time a variable is
• IBM DB2 11.1 (excluding IBM z/OS for all changed, remembering the old value. With big
versions) data objects stored and changed often, this
• PostgreSQL 9.6/ 10 / 11 / 12 / 13 requires a lot of space.
• Amazon Aurora PostgreSQL compatible with
PostgreSQL 9.6 / 10.4 / 10.7 / 10.13 / 12.4 When calculating database size, you should also
• Microsoft SQL Server 2014 / 2016 / 2017 / 2019 clarify if and how often you will be cleaning up
(more information) historical data. The real space occupied within your
• Microsoft Azure SQL with Camunda-supported database depends very much on your database
SQL Server compatibility levels (more product and configuration and there is no simple
information) formula to calculate this space.
• H2 1.4 (not recommended for production or
cluster mode; more information)
• CockroachDB v20.1.3 (more information)

camunda.com OCTOBER 2021

To learn more, please visit our Best Practices resource center.