NoSQL Consulting: Proven Architecture, Tuning & 24×7 Support

The shard-key rules NoSQL consulting applies are short. A good shard key has high cardinality, even frequency and non-monotonic values, or is hashed, and every hot query carries it so that the router targets one shard instead of scattering to all of them. Compound keys such as {tenant_id, ts} serve multi-tenant, time-ordered data well; a monotonic _id alone sends every insert to the last chunk. Resharding and refineCollectionShardKey exist, and 8.3 replaced removeShard with explicit startShardDraining and commitShardRemoval commands, but a wrong key still costs a rebalancing window, so it is decided at design review.

Write concern majority with journaling and read concern majority are the durable defaults; w:1 is acceptable for telemetry and nothing else. Causal consistency inside a session lets a client read its own writes from a secondary, which is what makes secondaryPreferred safe for reporting.

// the two commands a MongoDB review starts with
db.orders.find({ tenant_id: "t4x", status: "open" })
         .sort({ created_at: -1 })
         .explain("executionStats")
// look for: IXSCAN not COLLSCAN, totalKeysExamined close to nReturned,
// no SORT stage (index covers the sort), SHARDING_FILTER on one shard

db.orders.aggregate([{ $indexStats: {} }])
// indexes with accesses.ops = 0 since the last restart are write cost
// without read benefit; every extra index slows every insert and update

The 8.3 cost-based ranker changes plan selection for eligible queries; the metrics.query.cbr.* counters in serverStatus and the new query-memory tracking fields are now on our baseline dashboard, alongside WiredTiger cache pressure, replication lag, ticket availability and the slow-query log with its query-shape hash.

Cluster mode, which NoSQL consulting recommends above a single primary’s memory or throughput ceiling, shards the keyspace across 16,384 hash slots; keys that must be operated on together carry a {hash tag} so they share a slot, and the client handles MOVED and ASK redirects. Replicas sit in a different zone from their primary, and failover promotes in seconds. Persistence is a design choice: RDB for restart speed, AOF everysec for a one-second loss window, both for state that must survive, none for a pure cache that can be rebuilt. Eviction follows the role: allkeys-lfu for caches, noeviction with early maxmemory alerts for queues and state.

Redis and Valkey have diverged since the 2024 licence change. Valkey stays BSD-licensed under the Linux Foundation, and 9.1 brought hash-field expiry, database-level ACLs for multi-tenancy and a substantial reduction in string-key overhead; Redis 8.x folds search, JSON, probabilistic structures and vector sets into the core under its own licence. ElastiCache and MemoryDB now track Valkey. NoSQL consulting on this family therefore includes a licensing and feature divergence check, a Redis-to-Valkey migration path where it applies, and the memory-encoding review (listpack thresholds, fragmentation ratio, used_memory against dataset) that decides whether the instance is the right size at all. Details are on the Redis and Valkey support page.

NoSQL consulting for retrieval starts from the engines the estate already runs. MongoDB Atlas Vector Search, Cassandra 5.0 vector indexes, Redis vector sets and Couchbase 8.0 all put approximate-nearest-neighbour search beside the operational data, which keeps one system of record and simplifies filtered retrieval. Dedicated engines such as Milvus scale to billions of vectors with HNSW, IVF and DiskANN index types, GPU indexing and independent scaling of query and index nodes, at the cost of a second system to keep consistent.

We size on the measurable trade-offs: recall at a fixed latency budget on the real embedding distribution, index build time and memory per million vectors, filter selectivity against pre- and post-filtering strategies, and the freshness the application needs. The vector data engineering practice covers the pipeline side; the enterprise RAG architecture post covers the in-VPC reference design.

• MongoDB: three-member replica sets across three zones, priority and votes set deliberately, majority write and read concern, retryable writes on, and a restore drill from a backup that includes the oplog for point-in-time recovery.
• Cassandra and ScyllaDB: replication factor 3 per data centre, NetworkTopologyStrategy, rack awareness, LOCAL_QUORUM reads and writes, and a rehearsed loss of a data centre with the application’s consistency level unchanged.
• Redis and Valkey: cluster mode or Sentinel with replicas in other zones, min-replicas-to-write where loss matters, and a tested restore from RDB and AOF, because a cache that is really a database only reveals itself at restore time.

• DynamoDB and Cosmos DB: point-in-time recovery enabled and its window verified, global tables or multi-region writes where the RTO demands it, and a restore into a new table timed at production size.
• Cross-region designs choose deliberately between active-passive with asynchronous replication, active-active with conflict handling, and per-region isolation with a routing layer, with RPO, RTO and write latency written down for each.
• Quarterly drills: a timed restore and a timed failover, with the runbook corrected afterwards, under every NoSQL consulting retainer. The database SRE practice owns the SLOs and error budgets behind them.