For which kinds of workloads would you advise against adopting Space-Based Architecture, even though it scales well under bursty load, and why?

## The shape of the decision Space-Based Architecture is a targeted answer to a specific problem — a shared, synchronous database becoming the bottleneck or single point of failure under bursty, high-throughput load — and like any targeted solution, it's a poor choice whenever that specific problem isn't actually present, or whenever its costs outweigh a benefit the system doesn't need. Recognizing when NOT to reach for it is as much a senior architectural skill as knowing how it works. ## Steady, predictable load The first and most common case is steady, predictable load. If a system's traffic is roughly flat, or grows gradually and predictably, a properly indexed relational database with connection pooling, read replicas, and conventional caching (Redis/Memcached in front of hot keys) handles it perfectly well, and at dramatically lower operational cost than standing up and running a distributed in-memory data grid with processing units, partition rebalancing, and messaging-grid routing. SBA earns its complexity specifically during extreme, short-lived spikes: - flash sales; - ticket drops; - live-event traffic surges. In each, load can be 50-100x baseline for a brief window; outside that shape of traffic, you're paying the operational tax (more moving parts to monitor, more failure modes to reason about, engineers who need to understand a stateful distributed cache) without the corresponding payoff. ## Data sets too large for memory The second case is data sets too large to fit affordably in memory. RAM costs meaningfully more per gigabyte than disk, and an in-memory data grid's core value proposition depends on the working set fitting in the cluster's aggregate memory. This works fine for a bounded 'hot' data set — today's open orders, active sessions, live carts — but breaks down for systems whose relevant data set is inherently large and not naturally boundable to a small hot subset: - a data warehouse; - a full historical order archive; - a search index over millions of documents. Trying to keep all of that in an in-memory grid either becomes prohibitively expensive or forces awkward eviction/tiering schemes that erode the simplicity SBA is supposed to offer. ## Domains that need strict, immediate consistency The third, and most consequential, case is domains needing strong, immediate, multi-record consistency guarantees that write-behind's eventual, asynchronous persistence genuinely cannot provide safely. All of these are a bad match: - core double-entry ledger postings in banking; - anything where a regulator or an auditor expects the database to be the immediately-consistent, durable source of truth with no window where an acknowledged transaction could vanish on a crash; - business logic that spans multiple records in ways that need real ACID transactions (not per-partition atomicity). You can layer synchronous replication onto SBA to narrow the durability gap, as covered elsewhere, but you can't fully eliminate it without giving up the latency benefit that's the entire point of adopting the pattern — so for domains that truly cannot tolerate that gap, it's more honest to keep the database (or a database-backed pattern with real transactions) on the hot path and solve throughput a different way, such as sharding the database itself, using optimistic concurrency, or queueing writes for controlled-rate processing. ## Organizational readiness The fourth case is organizational: SBA requires real operational maturity to run safely. A distributed, stateful in-memory cluster introduces failure modes that a team needs to be able to detect, diagnose, and recover from in production, under pressure, often during exactly the high-traffic event that motivated adopting SBA in the first place: - split-brain during network partitions; - rebalancing storms during scale events; - replication lag causing stale reads; - write-behind queue backlogs. A team without prior experience operating distributed caches (Hazelcast, GemFire/Geode, GigaSpaces XAP) is taking on a steep new skill requirement, and a badly operated SBA deployment can be worse than the database bottleneck it replaced — silent data loss and split-brain inconsistency are harder to detect and recover from than a database that's merely slow or returning 503s under load, because at least the latter fails loudly and predictably. ## Getting it right versus getting it wrong A concrete, real-world illustration of getting this right versus wrong: - **The canonical good fit.** Airline and event-ticketing systems (GigaSpaces XAP's original flagship use case) are it — short, extreme demand spikes for a bounded set of inventory (seats, tickets) where a brief window of eventual consistency for non-critical fields is tolerable, and the business value of not falling over during the spike vastly outweighs the operational cost. - **A poor fit.** Conversely, a mid-size B2B SaaS product with smooth, predictable weekday traffic and a core requirement for exact, auditable billing records would be one — adopting SBA there would mean taking on distributed-cache operational risk and a durability trade-off for a scaling problem the system doesn't actually have, while the one data class (billing) that most needs strong consistency is exactly the class SBA handles worst. The right call in that second scenario is a well-tuned database (possibly sharded) plus targeted caching, not a wholesale architectural style switch.