| name | space-based |
| description | Use when implementing space-based architecture: horizontally scalable processing units, in-memory/distributed state, partitioning, eventual persistence, backpressure, replication, and operational safeguards for high-volume systems. |
Space-Based Architecture
Use this skill for systems where database bottlenecks and burst traffic dominate the design.
Fit
Use for high-volume, bursty, low-latency workloads needing horizontal scaling and elastic processing.
Avoid for ordinary CRUD systems; this pattern adds serious operational complexity.
Agent Workflow
- Read
graphify-out/GRAPH_REPORT.md.
- Run
graphify query "space-based architecture processing units partitioning replication".
- Identify the scalability bottleneck and partition key.
- Isolate processing unit logic from persistence.
- Make state ownership, replication, and recovery explicit.
- Add load, failover, and backpressure checks.
Target Shape
codebase/space/
processing-unit/ # stateless-ish compute plus owned partition state
partitioning # keying and routing
state-store # distributed/in-memory state port
persistence-sync # async persistence/replication
Implementation Rules
- Choose a stable partition key before code changes.
- Processing units own only their partition's hot state.
- Persistence is asynchronous where possible; consistency must be stated.
- Backpressure, retries, and overload behavior are part of the architecture.
- Recovery must rebuild state from durable sources or snapshots.
- Do not introduce distributed cache/state without observability.
Migration Steps
- Measure or identify the bottleneck.
- Extract hot-path processing into a processing-unit boundary.
- Add a state-store port with one implementation.
- Route requests/events by partition key.
- Add async persistence or snapshot/replay.
- Add load and failover tests around the boundary.
Verification
- Use graphify to confirm hot path does not synchronously depend on the old bottleneck.
- Test partition routing, duplicate processing, restart recovery, and overloaded dependencies.
- Record latency/throughput assumptions in an ADR.
Output Contract
Return: bottleneck, partition key, processing-unit patch, state/recovery model, verification, and operational risks.
