Documentation

What scales, and how

Component	Scaling model	Notes
Backend API	Horizontal	Stateless per request. Add instances behind a load balancer.
Collector	Horizontal	Stateless per request. Add instances, or place one per region.
Collector worker	Horizontal	Competing consumers on the broker. Add workers to drain faster.
Console	Horizontal	Static assets. Trivially replicated or served from a CDN.
Reverse proxy	Horizontal	Active-active behind a virtual address.
Database	Vertical, then replica set, then shards	The component that governs the ceiling.
Identity provider	Horizontal, clustered	Shares its own datastore.
Message broker	Clustered with quorum queues
Log store	Vertical, then object storage backend
AI service	Horizontal	Stateless. Conversation state is per session.

Session state is shared, not per process. A client's session resolves on any instance, so adding backend instances needs no sticky sessions at the load balancer.

Failure isolation

The platform is built so that the loss of one capability does not take the others with it. This is what makes a partial outage survivable.

Lost component	Effect
Discovery or ingestion path	The existing inventory stays fully readable and reportable. New results queue rather than being lost.
Message broker	Agents spool results locally and republish when it returns. A scan is delayed, not destroyed.
Telemetry pipeline	No functional impact. Services fall back to local logging.
AI service	No impact on any other function.
Identity provider	Existing sessions continue until expiry; new sign-ins fail.
Database	Full outage. This is the one component whose loss stops the platform.

The broker spool is the reason an ingestion outage is not a data-loss event. The agent writes results to its own disk before publishing and only removes them once every chunk is confirmed. An unreachable broker leaves the scan spooled on the target for a later attempt, rather than discarding work that took hours to produce.

Tier 1 — single node with cold standby

All services on one host. Resilience comes from backup and restore rather than redundancy.

        Operators, target hosts
                 |
                 v
        +------------------+
        |   Single node    |
        |  all services    |
        +------------------+
                 |
            daily backup
                 |
                 v
        +------------------+
        | Standby node     |   restore on failure
        +------------------+

Recovery is a restore, so the recovery time is the restore time. Exercise it; an untested restore is an assumption, not a plan.

Tier 2 — application and database separated

        Operators, target hosts
                 |
                 v
        +-------------------------+
        |    Application node     |
        |  proxy, API, collector, |
        |  console, broker, AI    |
        +-------------------------+
                 |
                 v
        +-------------------------+       +------------------+
        |     Database node       |<----->| Warm standby     |
        |  primary               |       | (optional replica)|
        +-------------------------+       +------------------+

Separating the database is the single most valuable step above Tier 1: it stops an analysis pass and a database compaction competing for the same memory, and it lets each be sized and tuned for what it actually does.

Add a database replica set here if the recovery objectives justify it. Two members plus an arbiter gives automatic failover; three full members gives failover and a read replica.

Tier 3 — role-separated with automatic failover

                     Operators, target hosts
                              |
                    +---------v---------+
                    |   Load balancer   |   active-active
                    +---------+---------+
                              |
            +-----------------+-----------------+
            |                                   |
   +--------v--------+                 +--------v--------+
   | Application 1   |                 | Application 2   |
   | proxy, API,     |                 | proxy, API,     |
   | collector, AI   |                 | collector, AI   |
   +--------+--------+                 +--------+--------+
            |                                   |
            +-----------------+-----------------+
                              |
        +---------------------v---------------------+
        |        Database replica set (3)           |
        |   primary  +  secondary  +  secondary     |
        |        automatic primary election         |
        +-------------------------------------------+
                              |
        +---------------------+---------------------+
        |                                           |
+-------v-------+                          +--------v-------+
| Identity node |                          | Observability  |
| clustered     |                          | node           |
+---------------+                          +----------------+

Quorum. A three-member replica set tolerates the loss of one member and elects a new primary automatically. It does not tolerate the loss of two: with one member left there is no majority and the set goes read-only. If the deployment spans availability zones, place the three members in three zones, not two.

Why the identity provider gets its own node. It is the only component whose brief unavailability blocks new sign-ins for everybody, and it has a very different resource profile from the rest — a JVM with a fixed heap, low CPU, no sustained disk. Isolating it stops a discovery burst from affecting sign-in.

Tier 4 — enterprise and multi-region

Above Tier 3 the changes are:

Sharded database. Two or more shards, each a three-member replica set, plus three config servers. Plan the shard key before deploying; changing it later is a migration.
Regional collectors. Place a collector and a broker in each region that scans, so result submission stays inside the region and only consolidated data crosses the WAN.
Autoscaled application tier. Three or more instances, scaled on request rate.
Multi-zone placement with a documented and exercised cross-region failover.

Size this from a capacity study rather than a table.

Scaling the discovery path

Discovery scales differently from the platform, because its limits are in the targets and the network rather than in CBOM Secure.

Constraint	How to address it
Concurrent target hosts per task	Configurable and bounded. Raise it to scan faster; keep it bounded so one task cannot exhaust the network or the target estate.
Ingestion throughput	Add collector workers. They are competing consumers, so throughput scales close to linearly until the database write path saturates.
Deduplication backlog	Runs as a background pass. A backlog drains without operator action; watch its depth rather than its rate.
Bandwidth	At least 10 Mbps per 1,000 concurrently scanning hosts.
Very large estates	Stagger tasks rather than scanning everything at once. A weekly full-estate scan split across seven daily tasks gives the same coverage at a seventh of the peak.

What to monitor for capacity

Signal	Why it matters
Deposit backlog depth	The earliest indicator that ingestion is falling behind discovery.
Database working-set pressure	The point at which query latency starts to degrade, well before storage fills.
Storage utilisation	Capacity, and headroom for compaction and restore.
Failed ingestion rate	Distinguishes a throughput problem from an authentication or schema problem.
Failed discovery task rate	Usually a target-side or credential problem rather than a platform one.
Analysis pass duration	Grows with inventory; a good leading indicator for the next tier.

Recovery objectives by tier

Tier	Recovery time	Data at risk	Mechanism
1	4 hours	24 hours	Restore from backup to a standby node
2	2 hours	4 hours	Warm standby application node; database restore or replica promotion
3	1 hour	1 hour	Active-active application tier; automatic database failover
4	30 minutes	15 minutes	Multi-zone, sharded, documented regional failover

These are the objectives the topology is capable of. Whether a given deployment meets them depends on its backup cadence and on whether the restore has been exercised — see Backup and Recovery.

Design rules worth keeping

Health checks on every long-running service, with automatic restart on failure.
Dependency-gated startup: nothing starts until what it depends on reports healthy. This prevents the cascade of confusing failures that follows a cold start in the wrong order.
Explicit resource limits on every service, so one cannot starve another.
An interrupted discovery task is safely re-runnable. Ingestion is idempotent on resubmission, so a re-run updates rather than duplicating.
Ingestion fails closed on an authentication error. There is no unauthenticated fallback path.

CBOM Secure

High Availability and Scaling