Scaling
This page tells you how to grow an adapter pool once you have picked a deployment topology: how to raise replica count for integrations that can absorb more pods, how to shard for integrations that cannot, and how to size each pod's resources. For the decision model on which topology to pick, see Deployment Topologies.
Before you raise replica count
Persistent-connection session protocols (stateful, sequence-tracked, single-owner) corrupt themselves if two pods try to own the same session. Raising replica count on this category adds standby capacity, not throughput. The correct technique for this category is session sharding, described below. If you have not already classified your adapter against the topology decision model, read Deployment Topologies first.
Raising replica count
Edit your values file:
adapter:
replicaCount: 5
Apply the change:
helm upgrade conncentric oci://<your-registry>/conncentric/charts/conncentric --version <release-tag> -f my-values.yaml -n conncentric
New pods start, register with the orchestrator, and either compete for the lease on a Single Writer adapter or join the external system's work distribution for a Scale Out adapter. Scaling down works the same way in reverse: lower replicaCount and run the upgrade. The platform handles the rest; no manual assignment is required.
| Topology | What an additional pod adds |
|---|---|
| Scale Out (stateless or partitioned) | Throughput, up to the external system's partition count or concurrency ceiling. Additional pods beyond that ceiling sit idle and serve as failover capacity. |
| Single Writer (stateful single-owner, replicaCount >= 2) | Standby capacity only. Throughput is bounded by one pod on one session; scale by sharding instead. |
| Single Writer (replicaCount: 1) | Nothing. The pool is by definition one pod and the integration is offline during pod restarts. |
Session sharding
Session sharding divides a logical workload into multiple independent session configurations, each owning a distinct slice of the traffic. Each session is a separate single-owner integration. The sessions run in parallel on different pods, the counterparty sees multiple independent sessions, and aggregate throughput scales with the number of shards. Sharding is an operational pattern rather than a dedicated feature: it is implemented by creating multiple adapter configurations in the Portal, and the orchestrator's lease distribution naturally spreads them across the pool.
Each session is an independent single-owner integration. If Pod A fails, its lease times out and a standby claims session 1. At no point do two pods own the same session.
Choosing shard boundaries
The right shard boundary is determined by whatever property makes two messages independent of each other from the counterparty's perspective. The counterparty must agree on the sharding scheme, because it controls which session a given message flows on.
| Sharding dimension | When to use |
|---|---|
| By account or trading identity | Traffic is independent across accounts; account-scoped sequence numbers are acceptable. |
| By instrument or product class | Traffic volume varies dramatically across product classes and the counterparty supports separate sessions per class. |
| By geography or time zone | Traffic surges are correlated with regional markets; operational schedules differ per region. |
| By environment or tenant | Multi-tenant deployments where each tenant must be operationally isolated. |
The counterparty's support team is the authoritative source on which sharding dimensions are supported and how they are provisioned. Do not provision additional sessions without their prior sign-off; most counterparties treat each session as a contracted entity with its own sequence state.
Pool size for sharded deployments
| Configuration approach | Pool size |
|---|---|
| Three sharded sessions, each Single Writer | Four pods (three active plus one shared standby), or six pods (three active plus three dedicated standbys). |
| N sharded sessions | Recommended pool size: N plus one, expanding toward two N as the number of sessions rises. |
The platform's orchestrator distributes active leases across pods as pods become available. No special configuration is required to balance leases across the pool.
Resource sizing
Resource usage varies by protocol, message size, and throughput. Start with the chart defaults and tune based on observed behavior. The adapter defaults are:
adapter:
resources:
requests:
memory: 512Mi
cpu: 500m
limits:
memory: 2Gi
cpu: 2000m
Common signals that indicate resource tuning is needed.
| Signal | Likely resource to tune |
|---|---|
| Sustained CPU throttling under load | Raise CPU request and limit. |
| Inflight queue depth climbs during steady-state traffic | Raise CPU limit, or investigate a slow target. |
| OOM kills during bursts | Raise the memory limit. The pipeline's internal queue is auto-sized from the pod's heap, so a larger limit also enlarges the queue; no separate queue setting is required. |
| GC pause latency affecting counterparty timeouts | Raise the memory limit; the runtime sizes its heap as a fraction of that limit, tuned through the adapter.javaToolOptions value (see Helm Reference). |
The internal queue is not a Portal setting. By default the platform auto-sizes it from the pod's maximum heap (approximately 10 percent of the heap at an estimated 2 KB per message, clamped between 500 and 50,000 messages), so raising the memory limit raises the queue automatically. To pin an explicit capacity, set adapter.pipeline.queueCapacity in your Helm values; leaving it unset keeps the heap-based auto-sizing. The related adapter.pipeline.concurrency and adapter.pipeline.backpressureLimit knobs default to availableProcessors - 1 and 80 percent of the queue capacity respectively.
Troubleshooting
| Symptom | Likely cause | Action |
|---|---|---|
| Scaled up the pool but throughput stayed flat | Every adapter in the pool is a stateful single-owner integration. Extra pods are standbys and do not add throughput. | Use session sharding instead. See above. |
| Counterparty reports duplicate messages shortly after a deployment | The integration was treated as stateless and multiple pods attempted to own the session during a brief lease handover window. | Confirm the deployment mode is Single Writer for stateful integrations. Investigate the events log for the lease transition. |
| Pods sit idle after joining a stateless partitioned pool | The external system has fewer partitions than pods. | Add partitions at the external system or reduce replica count to match. |
| Shard-count expansion is blocked by the counterparty | Most counterparties require explicit onboarding per session. | Work with the counterparty's technical support team before provisioning additional session configurations. |
Monitoring signals
| Signal | What it tells you | Alert when |
|---|---|---|
| Partition lag per consumer in a stateless partitioned pool | Whether the pool is keeping up with the external producer | Growth without recovery; stable lag is tolerable, unbounded growth is not |
| Lease-distribution skew across pods | Whether one pod is holding disproportionately many configurations | Persistent skew on a pool where load distribution matters |
See Metrics for the platform's exported metric names and example PromQL behind these signals.