2nd/10_Wiki/Topics/Domain_Programming/Architecture/Space-Based_Architecture.md

id, title, category, status, canonical_id, aliases, duplicate_of, source_trust_level, confidence_score, verification_status, tags, raw_sources, last_reinforced, github_commit, tech_stack

id	title	category	status	canonical_id	aliases	duplicate_of	source_trust_level	confidence_score	verification_status	tags	raw_sources	last_reinforced	github_commit	tech_stack
wiki-2026-0508-space-based-architecture	Space-Based Architecture	10_Wiki/Topics	verified	self	Space-Based Architecture SBA Tuple Space Architecture	none	A	0.85	applied	architecture scalability in-memory-data-grid		2026-05-10	pending	language framework java 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)

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

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)

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

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

@AffinityKeyMapped Long customerId; // 매 same partition 의 customer + orders

Near cache (read-heavy)

NearCacheConfig near = new NearCacheConfig()
    .setInMemoryFormat(InMemoryFormat.OBJECT)
    .setTimeToLiveSeconds(30);

Continuous query (event subscription)

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