System requirements and sizing

Purpose

This page is intended for architects, DevOps engineers, and customers who are planning Cabinee infrastructure.

The configurations below are starting guidelines, not guaranteed performance limits. Final sizing is determined by peak process, user, API, and integration load, data volume, and retention periods.

Architecture and calculation boundaries

User requests pass through the public access layer to the Frontend and Application API. External systems can interact with the public API or Integration Runtime, and event exchange between components is performed through Kafka.

The application layer consists of separate components: Frontend, Application API, Process Engine, and, when used, Integration Runtime. Application API and Process Engine have different load profiles and separate logical PostgreSQL stores for Business Data and Process Data.

PostgreSQL, Kafka, and the Identity Provider can be deployed inside the Cabinee perimeter or provided by an external platform. If they are not included in the selected deployment profile, their resources are estimated separately. Resources for an external AI provider and local AI models are also outside the baseline profiles.

Minimum system requirements

The minimum configuration is intended for evaluation, demo, and functional testing without high-availability requirements.

Recommended starting profiles

CPU and RAM apply only to the application layer. Selecting a row by user count is not sufficient: the profile must also be checked against process steps/second, API_peak, payload size, attachments, and retention.

For Enterprise, infrastructure, HA/DR, RPO/RTO, and platform-service resources are determined by the customer architecture and confirmed by a separate capacity plan.

How to estimate the load profile

First fill in the sizing worksheet for a real peak period. A daily average does not replace the peak-window profile.

Process load

process steps/day = P_day × A

process steps/second = (P_day × A × K) / peak_window_seconds

peak_window_seconds is the duration of the real peak window. Load must not be spread evenly over 24 hours if the bulk of operations runs within 8–12 hours. The coefficient K is chosen from expected bursts and then refined from metrics.

User tasks

human tasks/second = (T_day × K) / peak_window_seconds

The C parameter additionally affects the number of parallel HTTP/WebSocket connections, concurrent API requests, and connection pools.

API load

If the actual or forecast API_peak is known, use it directly. If only daily volume is known:

API requests/second = (API_requests_day × K) / peak_window_seconds

For integrations, also account for payload, timeout, retries, concurrency, and external-system limits.

Attachments

attachment data in retention period =
    F_day × S_file × business_days_per_year × retention_years

required attachment storage =
    attachment data in retention period × reserve_factor

The reserve covers growth, indexes, service data, and operational headroom. Backup is calculated separately according to the adopted retention policy.

In the current product configuration, attachments may be stored in PostgreSQL, so their volume significantly affects database size, IOPS, and backup and restore time. reserve_factor is refined from actual data growth.

Process data

Do not use a universal “bytes per process” coefficient: size depends on BPMN models, number of tasks, variables, and history.

A safe estimation approach:

1. measure database growth on a test stand over a selected period;
2. correlate the growth with the number of created process instances and tasks;
3. adjust the result for R_process;
4. apply a reserve;
5. confirm the calculation with a load test.

estimated process storage =
    measured average storage per process instance
    × process instances in retention period
    × reserve_factor

measured average storage per process instance is determined on representative BPMN models with typical variables and payload.

AI load

AI features are estimated from AI_peak, context size, selected model, latency, and rate limits — not only from user count.

With an external AI provider, the bulk of computation runs outside the application layer, but Cabinee still uses resources for context preparation, network connections, and response processing. For a local model, GPU, CPU, RAM, and storage are calculated separately and are not part of the Cabinee baseline profiles.

Calculation example

Source profile:

Calculation:

process steps/day = 10 000 × 12 = 120 000

process steps/second = 120 000 × 3 / 28 800 = 12.5

human tasks/second = 2 000 × 3 / 28 800 ≈ 0.21

attachment data = 100 × 2 MiB × 250 working days
                = 50 000 MiB ≈ 48.8 GiB per year

Attachment volume is given without backup, indexes, and reserve. For a system that operates on every calendar day, use the actual number of working days in the year instead of 250.

The result is not a performance promise. It is used to choose a starting profile, which is then verified with a load test using real BPMN models, payload, integrations, and the attachment profile.

Applicability limits

• values are starting guidelines, not guaranteed capacity;
• resources of external PostgreSQL, Kafka, Identity Provider, AI provider, and monitoring are estimated separately;
• attachments, retention, payload, and peak load can change sizing substantially;
• production sizing is confirmed by a representative load test.

Scaling

Having multiple replicas by itself does not confirm HA. For Enterprise, failover and recovery requirements are determined by the customer architecture.

Configuration confirmation

The load test must reproduce the peak window, not a uniform average daily flow. The scenario includes real BPMN models, user tasks, typical process variables, API, integrations, and attachments.

During the test, monitor throughput and latency, CPU/RAM, JVM, connection pools, PostgreSQL IOPS and data growth, Kafka lag, errors, and external-service limits. A starting profile is accepted only after the target load is verified with the required headroom, and after a retest when the architecture or key process models change.