---
id: wiki-2026-0508-space-based-architecture
title: Space-Based Architecture
category: 10_Wiki/Topics
status: verified
canonical_id: self
aliases: [Space-Based Architecture, SBA, Tuple Space Architecture]
duplicate_of: none
source_trust_level: A
confidence_score: 0.85
verification_status: applied
tags: [architecture, scalability, in-memory-data-grid]
raw_sources: []
last_reinforced: 2026-05-10
github_commit: pending
tech_stack:
  language: java
  framework: hazelcast
---

# Space-Based Architecture

## 매 한 줄
> **"매 database bottleneck 의 제거 — 매 in-memory data grid (tuple space) + 매 processing units 의 horizontal scale"**. Linda tuple space (1985) 의 후예. 매 Gigaspaces, Hazelcast, Apache Ignite 가 매 commercial 구현. 매 high-volume, low-latency 의 trading, gaming, real-time bidding.

## 매 핵심

### 매 components
- **Processing Unit (PU)**: 매 stateless application + 매 local in-memory data partition.
- **Virtualized Middleware**:
  - *Messaging Grid*: load balancer.
  - *Data Grid*: 매 distributed in-memory cache (replicated/partitioned).
  - *Processing Grid*: 매 orchestrate distributed work.
  - *Deployment Manager*: 매 PU lifecycle.
- **Data Pumps**: 매 data grid → DB async write-behind.
- **Data Writers / Readers**: 매 eventual persistence.

### 매 trade-off
- **장점**: 매 elastic horizontal scale, 매 DB 의 single point of bottleneck X, 매 sub-ms latency.
- **단점**: 매 eventual consistency, 매 complexity 의 폭발, 매 in-memory cost 의 high, 매 split-brain risk.

### 매 응용
1. Online ticketing (Ticketmaster).
2. Real-time bidding (ad exchange).
3. MMO game state (player position grid).

## 💻 패턴

### Hazelcast IMDG — distributed map (Java 21)
```java
HazelcastInstance hz = Hazelcast.newHazelcastInstance();
IMap<String, Order> orders = hz.getMap("orders");
orders.put("o-123", new Order("sku-1", 99));
Order o = orders.get("o-123"); // 매 local or remote partition
```

### EntryProcessor — 매 data-local computation
```java
orders.executeOnKey("o-123", (EntryProcessor<String, Order, Void>) entry -> {
    var o = entry.getValue();
    o.markPaid();
    entry.setValue(o); // 매 in-place mutation, 매 network round-trip 1회
    return null;
});
```

### Write-behind to RDBMS (data pump)
```java
MapConfig cfg = new MapConfig("orders")
    .setMapStoreConfig(new MapStoreConfig()
        .setClassName("com.acme.OrderMapStore")
        .setWriteDelaySeconds(5)
        .setWriteBatchSize(100));
hz.getConfig().addMapConfig(cfg);
```

### Apache Ignite — SQL on data grid
```java
IgniteCache<Long, Order> cache = ignite.cache("orders");
SqlFieldsQuery q = new SqlFieldsQuery(
    "SELECT customerId, SUM(amount) FROM Order GROUP BY customerId");
cache.query(q).forEach(row -> System.out.println(row));
```

### Affinity colocation — 매 join-friendly partition
```java
@AffinityKeyMapped Long customerId; // 매 same partition 의 customer + orders
```

### Near cache (read-heavy)
```java
NearCacheConfig near = new NearCacheConfig()
    .setInMemoryFormat(InMemoryFormat.OBJECT)
    .setTimeToLiveSeconds(30);
```

### Continuous query (event subscription)
```java
orders.addEntryListener((EntryAddedListener<String, Order>) e ->
    eventBus.publish("order.created", e.getValue()), true);
```

## 매 결정 기준
| 상황 | Approach |
|---|---|
| Sub-ms read/write @ 100k+ TPS | Space-based (Hazelcast/Ignite) |
| Strong consistency 필요 | Traditional RDBMS / NewSQL (CockroachDB) |
| Read-heavy, eventual OK | CDN + cache-aside (Redis) |
| Stream-first | Kafka + Flink (event-driven) |

**기본값**: 매 default 가 X — SBA 의 specialized. 매 일반 backend → microservices + Postgres + Redis.

## 🔗 Graph
- 부모: [[Software Architecture]] · [[Distributed Systems]]
- 변형: [[Microservices]] · [[Event-Driven Architecture]]
- 응용: [[In-Memory Data Grid]]
- Adjacent: [[CAP Theorem & PACELC]] · [[Eventual Consistency]] · [[Apache Ignite]]

## 🤖 LLM 활용
**언제**: extreme write throughput, DB bottleneck, latency budget < 10ms.
**언제 X**: 매 일반 CRUD, 매 strong consistency 의 필요, 매 small team — 매 complexity 의 cost 의 huge.

## ❌ 안티패턴
- **SBA for CRUD**: 매 over-engineering. Postgres 의 sufficient.
- **Sync write-through to DB**: 매 SBA 의 point 의 lost — async write-behind 의 의도.
- **Single PU instance**: 매 distributed grid 의 X — 매 SPOF.
- **No backup partitions**: 매 node failure → data loss.

## 🧪 검증 / 중복
- Verified (Mark Richards, *Software Architecture Patterns* O'Reilly; Hazelcast 5.x docs 2025).
- 신뢰도 A.

## 🕓 Changelog
| 날짜 | 변경 |
|---|---|
| 2026-05-08 | Phase 1 |
| 2026-05-10 | Manual cleanup — full SBA spec with Hazelcast/Ignite patterns |