Oak clustering ⚡ (elective)
Purpose: What author clustering with MongoMK actually involves, and the questions to answer before choosing it.
Who this page is for
| Audience | Why it matters to you |
|---|---|
| Architects | Deciding |
| Platform engineers | Operating it if chosen |
⚡ Elective — read when the problem is real
Default enterprise answer is TarMK author + cold standby. Clustering is for genuine author-tier scale/HA requirements that a single beefy author cannot meet.
What clustering means in 6.5
Author 1 ─┐
Author 2 ─┼──▶ MongoDB replica set (nodestore) + shared blob store
Author 3 ─┘ │
▲ └─ oplog, majority write concern
└── LB with sticky sessions for authorsMultiple author JVMs share one MongoMK repository. Each maintains caches; cluster-wide consistency comes from the Mongo layer. Publish tier is unaffected (still independent TarMK instances).
The costs, honestly
| Cost | Detail |
|---|---|
| Ops surface | A production MongoDB replica set fleet with its own upgrade/backup/monitoring discipline |
| Performance profile | Network-bound repo ops; single-author TarMK is often *faster* than a small cluster |
| Complexity taxes | Sticky sessions, cluster-aware jobs/schedulers, leader-only tasks, cache invalidation subtleties |
| Licensing/infra | More author instances + Mongo infrastructure |
Decision questions
- Is the bottleneck actually author compute — or workflows/DAM processing that could offload (asset microservices patterns, dedicated workflow tuning)?
- Is the HA need zero-RTO, or would cold standby's minutes-RTO do?
- Concurrent author count: hundreds of active editors is cluster territory; dozens rarely is.
- Can the team operate MongoDB in production *tonight*? If not, that capability is part of the project cost.
If you proceed: dedicated Mongo expertise, production-shaped staging cluster, and load tests of author workloads (capacity planning ⚡) are prerequisites, not nice-to-haves.