What does a 'processing unit' (PU) bundle together in Space-Based Architecture, and why is that bundling important for how the system scales?

## What a processing unit is In classic layered architectures, the unit of horizontal scale is the stateless application server: you add more of them behind a load balancer, and they all reach through to one shared, stateful database tier. Space-Based Architecture inverts that by making the processing unit itself stateful and self-sufficient. A processing unit (`PU`) is a single deployable module that bundles three things together: - **(1) the business/application logic** that handles requests; - **(2) an embedded portion of the in-memory data grid** — either a partition (a shard of the total data set) or a full replica, depending on the caching topology chosen; and - **(3) a local processing engine** or execution container that runs the logic directly against that local in-memory data, without a network round trip to a separate database or cache server. The `PU` is typically deployed as an independent process or container, many identical copies of which run across a cluster. ## Why the bundling matters The reason this bundling matters is where it puts the latency and the scaling unit. - **Latency.** In a traditional three-tier design, even a 'fast' request still pays a network hop from the app server to a database or external cache; under load, that hop's latency and the shared tier's throughput ceiling both grow. By colocating logic and data inside the same `PU`, most reads and writes become local, in-process memory operations — no serialization over a socket to a separate server for the common case — which is what gets SBA into single-digit-millisecond response times even under heavy concurrent load. - **The scaling unit.** It also collapses the scaling question to one variable: need more capacity? Deploy another `PU`. Because each `PU` carries its own data (or can obtain its share of the data through the grid's partitioning/replication), adding a `PU` adds both compute and data capacity simultaneously, rather than requiring you to separately scale an app tier and then separately re-shard or resize a database tier — two operations that, in a traditional stack, often can't be done independently or quickly. ## The cost of statefulness The trade-off is that `PUs` are much harder to treat as disposable, interchangeable, purely stateless workers. A stateless app server can be killed and replaced with zero data-loss risk; a `PU` holding a live partition of data cannot be killed casually — its data has to be migrated, replicated, or persisted first, or that slice of the data set disappears with it. This pushes real operational complexity into the deployment and orchestration layer. A routing component (sometimes literally called a **messaging grid**) has to: - know which `PU` currently owns which partition or key range; - direct requests accordingly; - rebalance that ownership map whenever a `PU` joins, leaves, or fails. Compare this to a stateless tier where any instance can serve any request and the orchestrator's job is trivial (round-robin or least-connections). ## Failure modes Failure modes concentrate around this statefulness. - If a `PU` crashes and its partition **wasn't replicated to a backup** `PU`, that slice of in-memory data is gone until it's rebuilt from the backing database — meaning a naive single-copy-per-partition deployment turns a routine instance restart (something totally benign for a stateless app server) into a data-loss or unavailability event for whatever key range that `PU` owned. - **Rebalancing** after a `PU` joins or leaves is itself a moment of risk: while partitions are being migrated to restore even distribution, some keys can be temporarily unreachable or served with stale data, and the migration traffic itself competes with live request traffic for network and CPU, which is exactly the wrong moment for that contention if the `PU` was added because the cluster was already under load. - **Sizing `PUs` wrong** is another common issue: because each `PU` is scaled as one unit of both compute and memory together, a workload that's data-heavy but logic-light (or vice versa) can't be right-sized as easily as in a decoupled tier — you either over-provision memory to get enough compute, or over-provision compute to hold enough data. ## Where it shows up A concrete pattern that made this bundling recognizable is **GigaSpaces XAP's** 'Processing Unit' terminology directly (it's the literal deployment artifact name in that platform), where a `PU` jar bundles a Spring context, business POJOs, and a space (the embedded data partition) into one deployable unit that the XAP grid container runs; teams commonly use this shape for order-processing and trading systems where per-order logic (validate, price, reserve inventory) needs to sit millisecond-close to the order's own data.