Architecture
Monolith. Microservices. Modulith.
Now: Consolidith.
Every architecture pattern before Consolidith made a trade-off. We studied all of them and asked a different question: what if you didn't have to choose? What if the right answer was a single process that was deliberately complete?
The problem
A typical AI backend today
Building one AI application currently means running, operating, and paying for all of this before you write a single line of product code. Each box below is a separate service with its own infrastructure, team, and on-call rotation.
Relational & Document Storage
Separate server, separate ops, separate on-call
Graph Database
Separate server, separate ops, separate on-call
Vector / Embedding Store
Separate server, separate ops, separate on-call
RAG & AI Orchestration
Separate server, separate ops, separate on-call
Workflow Orchestration
Separate server, separate ops, separate on-call
Identity & Access Management
Separate server, separate ops, separate on-call
Secrets & Encryption
Separate server, separate ops, separate on-call
Full-Text Search
Separate server, separate ops, separate on-call
Observability & AI Evaluation
Separate server, separate ops, separate on-call
Security Operations (SIEM)
Separate server, separate ops, separate on-call
Hyperscaler Cloud
Vendor lock-in · egress fees · data residency risk · API rate limits
Developer Cloud
Simpler than hyperscalers · still requires multiple services · still cloud-dependent
Every card above is a separate service running 24/7, with its own servers, redundancy, network hops, monitoring dashboards, and on-call rotation. This is not a software architecture problem. It is an energy, cost, and operational complexity problem. Purple8 replaces every card with one process.
The evolution
Four generations of backend architecture
Each generation fixed the biggest problem of the one before it, but introduced a new one in its place. Consolidith is the first that doesn't require a trade-off.
1990s – 2000s
Monolith
One codebase, one database, one process.
2010s
Microservices
Split everything. Scale anything. Pay for all of it.
2020s
Modulith
One deployable unit with modular internals, better structured than a traditional monolith.
2026 →
Consolidith
One process. Complete stack. Designed for AI from the ground up.
Side by side
The full comparison
| Monolith | Microservices | Modulith | Consolidith ✦ | |
|---|---|---|---|---|
| Deployment unit | Single process | Dozens of services | Single process | Single process |
| Internal structure | Often tangled | Isolated per service | Modular | Modular + vertical domains |
| Operational complexity | Low | Very high | Low | Low |
| Data model | Single DB | Polyglot (each service owns its DB) | Single DB | Multi-model unified engine |
| Vector / graph search | External add-on | Separate vector + graph services | External add-on | Native, in-process |
| Workflow orchestration | None / hand-rolled | Separate (Airflow, Temporal) | None / hand-rolled | Embedded Journey Engine |
| AI / agent interface | Bolted on | Bolted on per service | Bolted on | MCP-native (82 tools, day one) |
| Security (auth, encryption) | Add later | Add per service | Add later | In-process, on by default |
| Memory model | Grows with data | Unbounded per service | Grows with data | Hardware-bounded memory management |
| AI output evaluation | External tool or none | Separate eval service (LangSmith, Arize) | External tool or none | Built in: every AI decision stored as queryable graph edges |
| Security operations (SOC) | External SIEM or none | Separate SIEM / threat detection | External SIEM or none | Autonomous SOC agent that detects and contains threats in-process |
| Services replaced | None | None; it is the services | None | 20+ external services |
| Runs on a laptop | ✓ | ✗ (12 Docker containers) | ✓ | ✓ |
Two things no prior architecture has
Built different at the architectural level
Every architecture before Consolidith treats AI evaluation and security as downstream concerns to bolt on after your backend is built. Purple8 changes that at the structural level.
AI Evaluation — built into the fabric
In every other architecture, AI evaluation is a separate service you connect to after the fact (LangSmith, Arize, Weights & Biases). You export data, wait for ingestion, and query a system that's always one step behind your live application.
In Purple8, every AI action — every RAG retrieval, every agent tool call, every model decision, every workflow transition — is written as an immutable edge in the same graph your application queries. Evaluation isn't downstream. It's co-resident with your data.
- ✦Query AI performance history the same way you query application data
- ✦Compare retrieval quality across model versions without exporting anything
- ✦Trace every agent decision back to the exact context it was given
- ✦Spot regressions in real time, not in the next morning's dashboard
Autonomous SOC Agent — not a log forwarder
Traditional SIEMs (Splunk, Microsoft Sentinel, Datadog Security) work by collecting logs from your systems and analysing them, always at a remove from the data itself. Detection latency is measured in minutes. Containment requires a human or a separately configured playbook.
Purple8's SOC agent runs inside the same process as your data. It can correlate access patterns, query anomalies, and relationship graphs in real time, because it doesn't need to ship logs anywhere. When a threat is detected, containment actions (block, isolate, alert) execute in the same process, in milliseconds, with no round-trip to an external system.
- ✦Behavioural rules evaluated against live data, not log exports
- ✦Graph-aware threat detection: spot anomalous access across entity relationships
- ✦Detection to containment in milliseconds, not minutes
- ✦Every security event is an auditable graph edge, queryable forever
What Consolidith eliminates
One binary. Twenty services retired.
Every item below is a separate service your team would otherwise provision, monitor, and pay for, running 24/7, even when idle.
Reference architecture
Building with Purple8
Four deployment patterns for architects — from a solo developer's first app to a production Kubernetes cluster. Every scenario runs the same binary; only the topology changes.
Reference Architecture
Fully air-gapped deployment
A complete, highly capable AI backend that never touches the public internet. Document ingestion, entity extraction, RAG, graph reasoning, workflow orchestration, and threat detection — all running on hardware you control, with no egress required.
All models pulled once and cached locally. No internet connection required after initial setup. RAM figures are for Q4_K_M quantisation (default Ollama quantisation). VRAM figures assume dedicated GPU inference via Ollama.
| Tier | Model | Params | CPU RAM (Q4_K_M) | GPU VRAM | Ollama pull command | Role in stack |
|---|---|---|---|---|---|---|
| Nano | qwen3:4b toolsthinking | 4B dense | ~2.6 GB | 4 GB | ollama pull qwen3:4b | DocIntel document classification, chunking hints, quick intent routing |
| Default | qwen3:8b toolsthinking | 8B dense | ~5.2 GB | 8 GB | ollama pull qwen3:8b | Entity extraction, relationship mapping, RAG synthesis, general Q&A |
| Capable | qwen3:14b toolsthinking | 14B dense | ~9.0 GB | 12 GB | ollama pull qwen3:14b | Complex structured extraction, multi-hop RAG, code understanding |
| Reasoning | deepseek-r1:32b thinking | 32B dense | ~20 GB | 24 GB | ollama pull deepseek-r1:32b | Legal/financial document analysis, multi-step planning, compliance reasoning |
| Flagship (efficient) | qwen3:30b toolsthinking | 30B MoE · 3B active/tok | ~19 GB | 24 GB | ollama pull qwen3:30b | High-quality RAG, agentic workflows — near-70B quality at 32B memory cost MoE: only 3B parameters activated per token — substantially faster inference than a 30B dense model |
| Flagship (max) | llama3.3:70b tools | 70B dense | ~40 GB | 48 GB | ollama pull llama3.3:70b | Highest-stakes reasoning, audit-grade legal analysis, agentic SOC decisions Performance comparable to Llama 3.1 405B per Meta benchmarks |
| Vision / OCR | gemma4:12b visiontoolsthinking | 12B vision+thinking | ~8 GB | 12 GB | ollama pull gemma4:12b | DocIntel image OCR, whiteboard parsing, diagram understanding, scanned PDFs Gemma 4: frontier-level vision at 12B; also suitable for audio document intelligence |
| Embeddings | nomic-embed-text embedding | 137M | ~0.3 GB | CPU only | ollama pull nomic-embed-text | All vector embeddings for Purple8 Graph HNSW index — 8192 token context For multilingual corpora swap to qwen3-embedding:4b (~2.6 GB) |
Source: ollama.com/library · August 2026. qwen3 series by Alibaba Cloud; deepseek-r1 by DeepSeek; gemma4 by Google; llama3.3 by Meta.
Service resiliency
Zero-downtime deployments — Blue/Green for Consolidith
Blue/green on a microservices stack means coordinating rolling updates across a dozen services, managing inter-service version compatibility, and hoping your orchestrator drains traffic correctly across all of them simultaneously. On a Consolidith, it is four steps and one binary.
Microservices blue/green
12 services × 2 deployment slots = 24 running instances minimum during any release. Each service must be compatible with its neighbours at both versions simultaneously.
Coordination surface
Every service needs its own cutover signal. Traffic draining must be coordinated. A single incompatible version skew rolls the whole fleet back.
Consolidith blue/green
One binary. One deployment slot. The entire stack — graph, vector, workflow, auth, encryption — updates together with a single swap.
Provision green
Spin up 3 new replicas from the new binary. No external services to update.
Warm the vector index
Green replicas replay the durable log and rebuild the in-memory vector index from Purple8 Hyper Graph. Typically 60–120 s for multi-million-node corpora.
Cut over load balancer
LB health checks confirm green is ready → shift 100% traffic in one atomic update. Zero connection drops.
Drain and terminate blue
In-flight requests complete on the old replicas. Terminate blue. Total downtime: 0 ms.
Coordination surface
One deployment unit, one health check endpoint, one rollback target. No inter-service version matrix to reason about.
Three replicas provide full HA for a Consolidith deployment. Compare that to the 36+ instances (3 replicas × 12 services) required for equivalent microservices resilience. The operational surface shrinks by an order of magnitude.
blue — current
primary read
green — new
Purple8 Hyper Graph
Replication-ready · AES-256 at rest
Durable Write Log
fsync before mutation · crash-safe replay
Prometheus /metrics
One endpoint · one alert surface
Instances for HA
36+ (3 × 12 services)
3 replicas
Rolling update steps
12 independent rollouts
1 binary swap
Version skew risk
Every service boundary
None — one release unit
The hard questions
The objections — answered directly
Technical buyers arrive with reasonable scepticism. Here's how Consolidith holds up against the four objections we hear most.
High availability on Purple8 means 3 replicas of one binary, not 36 instances of 12 separate services. You get the same resilience with a far smaller operational surface. Each replica is stateless at the application layer; persistent state lives in the storage engine, which replicates across nodes via the write-ahead log.
Consolidith scales down to a laptop and up to horizontal replicas without changing a single line of application code. What it removes is scaling complexity, not scaling capability. The hardware-bounded memory model means you will never need to re-provision infrastructure just because your data set grew.
Yes. Because all capabilities share the same process and storage engine, resource pressure is visible in one place rather than scattered across twelve dashboards. You scale the whole node horizontally by adding a replica, and the load balancer routes compute-heavy queries to the least-loaded node automatically. That is simpler than microservices, where you first have to identify which of twelve services is the bottleneck, provision it separately, and then manage the traffic between them. If you genuinely need workload isolation, for example bulk ingestion running alongside latency-sensitive API queries, Purple8 supports deployment topologies where ingestion nodes and query nodes run as separate replica sets from the same binary, with no code changes required.
Every capability is exposed through standard REST or MCP tools. Your application talks HTTP and nothing else. You can swap the backend while keeping the interface unchanged. AI agents have no visibility into what runs underneath their tool calls. The same lock-in concern applies to every managed service you currently depend on, multiplied by twelve.
Purple8 does not require a hard cutover. The REST ingest API and the data.* MCP tools accept structured records, documents, and embeddings directly. You can run both systems in parallel and migrate one entity type or collection at a time. Most teams start with a single new use case, such as a new RAG pipeline or a new workflow, rather than touching existing tables at all. The old stack stays live until you are ready to retire it.
Managed services solve the provisioning problem, not the integration problem. You still write the glue code between your managed vector store, your managed graph database, your managed workflow engine, and your managed auth service. Every one of those boundaries is a network call, a potential schema mismatch, and a separate monthly invoice. Purple8 removes the boundaries, not just the provisioning. A single pip install or docker run replaces the entire managed stack and runs identically on your laptop, on any cloud, and in an air-gapped environment.
The Python package is open to inspect, the REST and MCP interfaces are publicly documented, and the storage format is not proprietary binary. Your data does not become inaccessible if you stop using Purple8. The commercial tier adds support SLAs and enterprise features, but the core engine is not gated behind a cloud control plane. You are never one company decision away from losing access to your own data.
Fewer components means a smaller audit surface, not a larger one. A single process has one network exposure, one set of CVEs to track, one patching cadence, and one place to apply your encryption and access control policy. AES-256 encryption and the SOC agent are on by default, so your auditor is reviewing a system that is already hardened rather than one where security was added per service after the fact. Compliance artefacts including audit logs, access records, and data lineage are all queryable from the same graph, with no log aggregation pipeline required.
Purple8's REST API maps closely to concepts your team already knows. Nodes are records, edges are foreign keys, and vector search is a query parameter. The MCP tools are designed to be called in plain English by an AI agent, so your team does not need to learn a new query language. The Journey Engine maps directly to the workflow patterns your team currently builds in Airflow or hand-rolled state machines. We believe the ramp-up will be shorter than you expect, because there is no new query language to learn, no distributed system mental model to internalise, and no inter-service wiring to reason about. The complexity that typically drives long onboarding timelines simply is not there.
Yes. Purple8 ships as a standard container image and exposes a single HTTP port. It runs as a Kubernetes Deployment or StatefulSet with no custom operator required. The /health and /ready endpoints integrate directly with Kubernetes liveness and readiness probes, and the /metrics endpoint works with any Prometheus scrape configuration. Horizontal scaling is a replica count change. Nothing in your existing Kubernetes tooling needs to change.
Yes, and this is where the MCP-native design pays off most clearly. Migration in Purple8 is not a one-time, human-driven export and import operation. It is an ongoing, agent-orchestrated process that runs autonomously until complete, with a single human approval gate before the final cutover.
Agent reads from the source system
Point an AI agent at the source. It reads records through the source REST API, a direct database connector, or a file export. No bespoke migration script is needed.
Agent writes into Purple8
The agent calls data.ingest_text or data.ingest_file to push entities into Purple8 as graph nodes and edges, with relationships preserved rather than flattened into rows.
Journey Engine tracks progress
Each entity type or data partition maps to a stage in a MigrationJourney definition. SLA policies surface stalled stages automatically. Failed batches are retried without human input.
Agent verifies parity
graph.counts on Purple8 is compared against source record counts. Any gap triggers a targeted re-run of the affected stage rather than restarting the whole migration.
Single human approval gate
One HITL gate in the Journey definition. The agent presents a parity report; a human reviews and approves. Everything before and after this gate runs autonomously.
Reference architecture
Postgres
Pinecone
S3 / Files
Legacy API
Migration Agent
reads source · calls data.ingest_* · verifies parity
MigrationJourney
one stage per entity type · SLA monitoring · single HITL approval gate
Purple8 Graph
graph nodes · edges · embeddings · full-text search · all in one process
No big-bang cutover
Source and destination run in parallel throughout the migration. The old system is retired only after parity is confirmed and approved.
One human touchpoint
A single approval gate before cutover. The agent handles everything before and after that point without further human involvement.
Full audit trail
Every record ingested, every parity check, and every retry is stored as an immutable edge in the graph. Migration history is queryable indefinitely.
Honest assessment
Where scepticism is warranted
Consolidith is not the right answer for every team in every situation. These are genuine architectural trade-offs that technical buyers should evaluate carefully before committing. We would rather you understand them upfront than discover them six months into a deployment.
Placing multi-model storage, workflow orchestration, threat detection, and document parsing inside a single process creates a larger blast radius than a microservices architecture. A large bulk ingestion job pushing data through the graph write path competes for memory with live query operations on the same replica. If resource limits are not enforced at the Kubernetes level, a memory spike on one workload can affect everything else running in that replica.
What we do about it
Purple8 Hyper Graph uses bounded memory management that limits peak memory per ingestion batch rather than allowing it to grow with corpus size. The hardware-aware auto-configuration, enabled with a single flag, calculates batch geometry at startup to keep peak process memory within a configurable fraction of available RAM, defaulting to 75%. Beyond that, Purple8 supports dedicated replica sets from the same binary: ingestion nodes and query nodes run as separate Kubernetes Deployments with independent CPU and memory quotas, so an ingestion spike on one set cannot affect query latency on another. That topology requires deliberate configuration upfront. Teams running a single undifferentiated replica pool without resource quotas carry more blast radius exposure than they would with isolated microservices.
A single binary means every capability ships in the same release. A team that finds a bug in their RAG retrieval path cannot patch and redeploy that capability in isolation. They must build, test, and release the entire product artifact, including the storage engine, authentication layer, and everything else, regardless of whether those components changed.
The honest assessment
Purple8's blue/green deployment model means a full release is a four-step operation with zero downtime: spin up new replicas, warm the vector index, cut over the load balancer, drain the old set. The mechanical cost of releasing the full artifact is lower than it looks. The real consideration is test coverage: any release that touches the storage or write-ahead log path should go through the full regression suite. For teams iterating rapidly on a specific capability early in development, that full pipeline adds overhead that isolated microservices would not impose. For production systems where the storage and authentication layers are stable, this constraint rarely surfaces.
Purple8's vector search index is held entirely in memory. Graph traversals read from the storage engine at query time. The Journey Engine's SLA monitor runs as a live background process. The SOC agent evaluates threat detection rules continuously. All of these compete for the same CPU and memory on a single replica. In a microservices architecture each workload gets its own process with its own resource envelope. A spike in vector search concurrency can affect graph traversal latency on the same node if it is not sized for the combined load.
What we do about it
Horizontal scaling adds capacity to the whole node. That is less surgical than scaling a single microservice, but the operational cost is also far lower: one replica count change rather than identifying which of twelve services is under pressure and managing the downstream effects. The dedicated replica topology handles the most common case, separating bulk ingestion from latency-sensitive query traffic, with no code changes required. For teams with predictable, relatively homogeneous workloads the contention concern is manageable with correct node sizing. For teams running unpredictable concurrent spikes across vector search, graph traversal, and workflow execution simultaneously, workload separation and capacity planning require more upfront work than isolated services would.
Start today
Try it yourself, free
The Developer edition is free, runs on your own machine, and requires no external services. One command and you have a complete AI backend.
Free forever · No credit card · Runs on your own hardware
Talk to us
Request a guided demo
A Purple8 engineer will walk you through a deployment tailored to your stack, data scale, and use case. No slides — live code, your questions.