# Architecture Paradigm Space Based

> - When traffic or state volume overwhelms a single database node.

- Skill: `majiayu000/architecture-paradigm-space-based` (Agent Skill, multi-file: 2 files)
- Install (CLI): `npx skillmds add majiayu000/architecture-paradigm-space-based`
- Raw SKILL.md: https://api.skillmd.com/api/skills/majiayu000/architecture-paradigm-space-based/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: majiayu000 (https://skillmd.com/u/majiayu000)
- Updated: 2026-09-09
- Page: https://skillmd.com/skills/majiayu000/architecture-paradigm-space-based

---


---
name: architecture-paradigm-space-based
description: |

Triggers: data-grid, space, architecture, based, in-memory
  Data-grid architecture for high-traffic stateful workloads with linear scalability.

  Triggers: space-based, data grid, in-memory, linear scaling, high traffic
  Use when: traffic overwhelms database nodes or linear scalability needed
  DO NOT use when: data doesn't fit in memory or simpler caching would work.
version: 1.3.5
category: architectural-pattern
tags: [architecture, space-based, data-grid, scalability, in-memory, stateful]
dependencies: []
tools: [data-grid-platform, replication-manager, load-tester]
usage_patterns:
  - paradigm-implementation
  - high-traffic-workloads
  - linear-scalability
complexity: high
estimated_tokens: 800
---

# The Space-Based Architecture Paradigm

## When to Employ This Paradigm
- When traffic or state volume overwhelms a single database node.
- When latency requirements demand in-memory data grids located close to processing units.
- When linear scalability is required, achieved by partitioning workloads across many identical, self-sufficient units.

## Adoption Steps
1. **Partition Workloads**: Divide traffic and data into processing units, each backed by a replicated data cache.
2. **Design the Data Grid**: Select the appropriate caching technology, replication strategy (synchronous vs. asynchronous), and data eviction policies.
3. **Coordinate Persistence**: Implement a write-through or write-behind strategy to a durable data store, including reconciliation processes.
4. **Implement Failover Handling**: Design a mechanism for leader election or heartbeats to validate recovery from node loss without data loss.
5. **Validate Scalability**: Conduct load and chaos testing to confirm the system's elasticity and self-healing capabilities.

## Key Deliverables
- An Architecture Decision Record (ADR) detailing the chosen grid technology, partitioning scheme, and durability strategy.
- Runbooks for scaling processing units and for recovering from "split-brain" scenarios.
- A monitoring suite to track cache hit rates, replication lag, and failover events.

## Risks & Mitigations
- **Eventual Consistency Issues**:
  - **Mitigation**: Formally document data-freshness Service Level Agreements (SLAs) and implement compensation logic for data that is not immediately consistent.
- **Operational Complexity**:
  - **Mitigation**: The orchestration of a data grid requires mature automation. Invest in production-grade tooling and automation early in the process.
- **Cost**:
  - **Mitigation**: In-memory grids can be resource-intensive. Implement aggressive monitoring of utilization and auto-scaling policies to manage costs effectively.
## Troubleshooting

### Common Issues

**Command not found**
Ensure all dependencies are installed and in PATH

**Permission errors**
Check file permissions and run with appropriate privileges

**Unexpected behavior**
Enable verbose logging with `--verbose` flag