146: Advanced MongoDB Features — Change Streams, Time Series, GridFS, Geospatial, Search, Vector Search, and Specialized Workloads

Learning objectives

You will learn to:

• choose specialized MongoDB features based on workload;
• design reliable change-stream consumers;
• understand time-series collections;
• understand GridFS and when not to use it;
• model geospatial data and queries;
• distinguish classic text indexes from MongoDB Search;
• understand MongoDB Vector Search;
• understand hybrid search at a practical level;
• understand specialized feature limitations;
• avoid forcing every data problem into one MongoDB feature.

The goal is not to memorize a catalog of MongoDB operators. It is to learn where each subsystem fits, what assumptions it makes, and which trade-offs become visible in production. By the end, you should be able to recognize a workload, choose a suitable feature, and identify the boundaries where an ordinary collection or another service is the better answer.

Why specialized features come late

Specialized features are easier to use safely once the core database model is familiar. You first learned:

documents
modeling
CRUD
indexes
aggregation
transactions
replication
sharding
security
operations
driver

Those concepts are the foundation for the topics here. For example, a change stream still has delivery and recovery concerns, a vector query still needs authorization filtering, and a geospatial query still depends on an index and a sound data model. Now you can evaluate specialized features without treating them as magic.

Change streams recap

An application often needs to react after data changes: update a projection, invalidate a cache, publish an event, or start another workflow. Polling for changes adds latency and usually requires keeping track of what has already been seen. Change streams provide a database-backed subscription instead.

Change streams let an application subscribe to MongoDB changes on:

• collection;
• database;
• deployment.

They are available on replica sets and sharded clusters. A stream is not a general message broker, however. The consumer still needs durable progress tracking, retry behavior, and an idempotency strategy.

Example:

const stream = db
  .collection('orders')
  .watch([
    {
      $match: {
        operationType: {
          $in: [
            'insert',
            'update',
          ],
        },
      },
    },
  ]);

This pipeline limits the stream to inserts and updates for the orders collection. Filtering closer to the source avoids making every consumer inspect events it cannot use, although it does not remove the need to handle reconnects or failures.

Consume:

for await (const change of stream) {
  await handleChange(change);
}

The await makes the example process one event at a time. A real consumer may use controlled concurrency, but it must preserve whatever ordering the business operation requires and must not acknowledge progress before the corresponding work is durable.

Change event shape

Can include fields such as:

_id                 resume token
operationType
clusterTime
ns
documentKey
updateDescription
fullDocument
fullDocumentBeforeChange

The exact event depends on the operation, stream scope, requested options, server version, and collection configuration. Do not assume fullDocument is always present. An update event may describe changed fields without carrying the complete post-update document.

Full document lookup

For updates, request the post-change document with a supported option such as:

fullDocument: "updateLookup"

This performs a lookup and can add load. It is useful when the consumer genuinely needs the resulting document, but it is unnecessary overhead when the changed field names and values are enough.

If you only need changed field names, use updateDescription. This is also a reminder to define the consumer's input contract rather than fetching more data by default.

Pre/post images

MongoDB can store pre/post images for configured collections. They are useful when a consumer needs to compare the old and new versions instead of reconstructing the difference itself.

Useful for:

• audit;
• diff;
• event processors requiring old/new.

Costs:

• storage;
• privileges;
• retention;
• operational complexity.

Do not enable globally without need. First identify which collections and workflows require images, then account for their retention and storage impact.

Resume

A long-running consumer needs to recover after a process restart or temporary outage. Store the resume token after successfully applying the event:

receive
↓
process idempotently
↓
persist output/state
↓
persist resume token

If you persist the token before completing the side effect, a crash can make the consumer skip unfinished work when it resumes.

If you persist the token after a non-idempotent side effect, a crash can repeat that side effect. That is why consumers should be idempotent, and why the output/state and progress record often need a carefully designed durable boundary.

In practice, inspect the consumer's retry path as carefully as its happy path. A useful test is to stop the process between each pair of steps and then restart it from the saved token. The result should be either one durable business outcome or a retry that the application can recognize and safely absorb.

Change stream and exactly-once myth

A change stream alone does not automatically produce exactly-once external side effects. The database can deliver an event again after a failure, and an external service may accept a request before the consumer crashes.

For:

send email
charge card
publish webhook

use mechanisms such as:

• idempotency keys;
• durable processed-event record;
• outbox;
• transactional projection design.

The useful distinction is between event delivery and business effect. A consumer can provide at-least-once processing while still making the business operation behave safely on retries.

Rebuildable projection

A robust read-model consumer should ideally support:

rebuild from source
+
resume live changes

If resume history expires, you can rebuild. This separates recovery of a derived projection from recovery of the source of truth.

Do not make one forgotten resume token the only way to reconstruct critical data. Keep the source data authoritative and make the projection process observable enough to detect lag, failure, and replay.

Time-series data

Telemetry systems usually append measurements with a timestamp and a stable series identity. Sensors, metrics, and IoT devices are common examples, but the same model can apply to other measurement workloads.

Workloads:

• sensors;
• metrics;
• IoT;
• telemetry;
• measurements.

Time-series collection groups data by:

time field
meta field
granularity/bucketing

The time field identifies when a measurement occurred. The meta field identifies the series or stable context, and bucketing lets MongoDB organize nearby measurements efficiently. These are storage and query-design choices, not merely extra document fields.

Example:

db.createCollection(
  "deviceMetrics",
  {
    timeseries: {
      timeField: "timestamp",
      metaField: "device",
      granularity: "seconds"
    }
  }
)

Document:

{
  timestamp: new Date(),
  device: {
    tenantId,
    deviceId,
    region: "south"
  },
  temperature: 28.4,
  humidity: 63
}

Here, timestamp is the measurement time and device describes the series. The measurement values remain ordinary fields, but the collection configuration tells MongoDB how to organize the time-oriented workload.

Time-series meta field

Put stable metadata used to group or filter into the meta field:

device ID
sensor type
tenant
site

Avoid frequently changing, high-cardinality metadata structures that defeat efficient bucketing. A field that changes for every measurement does not describe a stable series and can prevent related measurements from being grouped effectively.

Design from query patterns. Ask which measurements are read together, which dimensions identify a series, and what retention and aggregation windows the application needs before choosing the collection options.

Time-series limitations

Time-series collections have specific limitations. A feature that works on an ordinary collection may not be available in the same form here.

As of current MongoDB documentation:

• change streams are not supported on time-series collections;
• MongoDB Search/Vector Search is not supported for time-series collections in the ordinary way;
• some schema/collection operations have restrictions.

Check the current version before choosing. Product capabilities and restrictions change, and deployment type can matter.

Do not assume a normal collection feature automatically works on time series. If the application needs both measurement storage and a downstream change-driven workflow, model that boundary explicitly rather than discovering the incompatibility after deployment.

Time-series retention

Use expireAfterSeconds for automatic data expiration where appropriate. This is useful for operational telemetry whose value declines after a known period.

TTL cleanup is asynchronous. Expired data should therefore not be treated as disappearing at an exact deadline.

For regulatory or analytics retention, design archival before expiry. Automatic cleanup is not an archival strategy; move or summarize data first when the business must retain it.

Retention is also a cost boundary. Estimate the incoming measurement rate, document size, index overhead, and expected query window before selecting a retention period. A short TTL can keep the hot collection manageable, but it does not remove the need to monitor disk growth while cleanup catches up.

Downsampling

High-frequency telemetry can be expensive long-term. A common design keeps detailed data briefly and preserves lower-resolution summaries longer:

raw 1-second metrics retained 7 days
5-minute aggregates retained 1 year

Use aggregation, materialized summaries, or Atlas features according to the workload. Decide which questions require raw readings and which can be answered from aggregates before deleting the detailed data.

GridFS

MongoDB documents have a size limit, while applications sometimes need to store larger files. MongoDB GridFS addresses that mismatch by splitting a large file into chunks and storing metadata alongside those chunks.

MongoDB GridFS stores large files by splitting them into chunks plus metadata.

Collections conceptually:

fs.files
fs.chunks

Use when:

• files need MongoDB-managed storage semantics;
• files exceed document size;
• operational architecture favors DB-backed file storage.

GridFS gives the application a MongoDB-oriented file interface, but it does not make a database the best media-serving system. Storage, serving, caching, and authorization still need separate design decisions.

When object storage is better

For:

• photos;
• videos;
• PDFs;
• public assets;
• large downloads;

S3-compatible/object storage plus a CDN is often better because it provides:

• cheaper;
• scalable;
• range requests/CDN;
• lifecycle policies;
• specialized durability.

GridFS is not automatically the right choice just because the application already uses MongoDB. Compare cost, throughput, range-request behavior, CDN integration, lifecycle management, backup strategy, and access-control needs.

The decision should include recovery behavior as well. If the database is unavailable, a file path that depends on the database is unavailable too; if files are independently stored, the application must define how metadata and object state are reconciled. Neither option removes the need for checksums, upload status, and cleanup of abandoned uploads.

GridFS Node driver

The Node driver exposes GridFSBucket. The important implementation detail is to stream rather than load the whole file into memory.

Concept:

const bucket = new GridFSBucket(db);

await pipeline(
  fileInput,
  bucket.openUploadStream(
    safeFilename,
    {
      metadata: {
        tenantId,
      },
    },
  ),
);

Download:

await pipeline(
  bucket.openDownloadStream(fileId),
  httpResponse,
);

Use streaming and backpressure. The filename and metadata in this example are not authorization by themselves; the application must verify that the requesting user can access the file identified by fileId.

GridFS security

Do not trust the original filename for authorization. A filename is user-controlled metadata and can be duplicated, changed, or crafted to mislead an operator.

Useful metadata may include:

tenantId
ownerId
contentType
size
hash/scanning status

The application query should scope the file ID and tenant together. Do not fetch an arbitrary file by ID and perform tenant checks only after opening or returning its contents.

Uploaded-file policy remains:

• size limit;
• MIME/signature;
• malware;
• content-disposition;
• safe serving.

The declared MIME type is not sufficient to establish what a file contains. Validate the upload, scan it according to the product's risk, and serve it with headers and behavior appropriate to untrusted content.

Geospatial model

Location bugs are often data-model bugs rather than query bugs. GeoJSON uses a fixed coordinate order, so establish that convention before inserting data.

GeoJSON Point:

{
  location: {
    type: "Point",
    coordinates: [
      78.1198,
      9.9252
    ]
  }
}

Coordinates are:

longitude
latitude

Index:

db.places.createIndex({
  location: "2dsphere"
})

The 2dsphere index supports geographic queries over a spherical model. If longitude and latitude are reversed, the query can still execute successfully while returning places in the wrong location, which makes this a particularly deceptive failure mode.

Validate coordinates at the application boundary and include a small set of known locations in tests. Also decide whether missing, malformed, or out-of-range coordinates should reject the document. A valid GeoJSON shape is not proof that the location is meaningful for the product.

$near

Find nearest places:

db.places.find({
  location: {
    $near: {
      $geometry: {
        type: "Point",
        coordinates: [
          78.12,
          9.92
        ]
      },
      $maxDistance: 5000
    }
  }
})

Use the geospatial index. Distance units depend on the operator, so check the current documentation and confirm the result with known coordinates rather than guessing.

$geoWithin

Find points inside a polygon or other supported shape. This is useful when the question is membership in a boundary rather than nearest-neighbor ordering.

Useful for:

• service area;
• delivery zone;
• geofencing.

Geospatial boundary precision and coordinate-reference assumptions matter. Do not implement legal or cadastral precision blindly with general GeoJSON. Validate the accuracy requirements and the source coordinate system before treating a boundary result as legally authoritative.

$geoNear

The aggregation stage can calculate distance and enrich output. It must follow stage and index rules, so check the pipeline constraints before composing it with other stages.

Useful:

nearest stores
then lookup inventory
then filter availability

This can express a practical store-locator workflow, but the query may become expensive. Measure the candidate count, lookup work, sort behavior, and tenant filtering rather than assuming that the geospatial index makes the whole pipeline cheap.

Classic text search

Classic MongoDB text indexes support basic search. They are a reasonable fit for simple workloads, but they are not interchangeable with MongoDB Search.

db.articles.createIndex({
  title: "text",
  body: "text"
})

Query:

{
  $text: {
    $search: "mongodb indexing"
  }
}

Useful for simple workloads. It is limited compared with MongoDB Search, particularly when the product needs richer relevance, analysis, autocomplete, fuzzy matching, facets, or highlighting.

MongoDB Search

MongoDB Search provides Lucene-based search capabilities in supported deployments and products. It is a separate search subsystem with its own index definitions and operational behavior.

Capabilities include:

• relevance;
• analyzers;
• autocomplete;
• fuzzy matching;
• facets;
• compound search;
• highlighting.

Search indexes are managed separately from normal MongoDB indexes. The pipeline uses:

$search
$searchMeta

Do not use createIndex() and expect Atlas Search behavior. A normal database index and a Search index have different purposes, configuration, and lifecycle.

Search index mapping

Define fields and analyzers deliberately. Dynamic mapping is easy for prototypes, but it can index more fields than needed and increase resource use or produce surprising search behavior.

For production, decide explicitly on:

• searchable fields;
• analyzers/language;
• stored source choices;
• autocomplete;
• synonyms where appropriate.

Search indexing consumes storage and resources. Treat mapping changes as an operational change that may require a new build, validation, and a controlled traffic switch.

Autocomplete

A prefix-like user experience should not rely on an unbounded regular expression over millions of documents:

{
  name: {
    $regex: userInput,
  }
}

Search autocomplete indexes and operators can provide better scalable relevance behavior. The right choice still depends on the shape of the query, the number of documents, and the expected latency, so measure rather than assuming either approach is free.

Search security

Search results must still enforce tenant and access scope. Search relevance is not an authorization mechanism.

Include the tenant filter in the search pipeline using supported compound filters or the application's query architecture. Do not search a global index and filter unauthorized results only after returning too many results. Authorization belongs before or exactly within the data query, both to prevent disclosure and to avoid wasting work on results the user cannot see.

Vector search

Keyword search answers questions about terms. Vector search finds semantically similar vectors, which can connect differently worded content when their embeddings are close in the selected vector space.

Typical flow:

text/image/document
↓
embedding model
↓
vector array
↓
vector index
↓
nearest-neighbor query

Document:

{
  tenantId,
  content: "...",
  embedding: [
    0.013,
    -0.22,
    ...
  ]
}

The embedding is derived data. The model, dimensions, preprocessing, and similarity metric are part of the data contract, not incidental implementation details.

Vector index

MongoDB's vector search uses a specialized vector index in supported deployments. The query uses the $vectorSearch stage.

Concept:

{
  $vectorSearch: {
    index: "content_vector",
    path: "embedding",
    queryVector: [...],
    numCandidates: 200,
    limit: 10,
    filter: {
      tenantId: tenantId
    }
  }
}

Exact supported filters and options depend on the current MongoDB version and service. Do not copy dimensions or index settings from another embedding model. Verify the deployment's supported syntax and make sure the query vector has the expected shape.

Embedding dimensions

Vector size must match the index and model. If the model changes:

1536 dimensions
→ 3072 dimensions

existing index and data may require a migration, a new field, or a new index. Store the model identity with the vector so a worker can tell which data is compatible.

Version embeddings:

{
  embeddingModel: "model-x-v2",
  embedding: [...]
}

Changing a model without a migration plan can lead to rejected queries, mixed vector populations, or silently inconsistent relevance.

Similarity function

Vector indexes support similarity metrics such as cosine, dot, or euclidean, depending on the service and configuration. Match the metric to the embedding model's recommendation.

Do not choose a metric by intuition. The metric changes what “near” means, and a technically valid query can still produce poor results if the model and index assumptions do not match.

Hybrid search

Many products need both exact terms and semantic similarity. Hybrid search combines:

lexical relevance
+
semantic/vector relevance

It is useful when exact terms matter and semantic similarity helps. For example:

"Node 26 memory leak"

Lexical search can preserve the exact version term, while semantic search can retrieve material about the underlying memory problem even when it uses different wording.

Hybrid ranking may use reciprocal-rank fusion or product-specific scoring. Use MongoDB's current Search and Vector capabilities rather than manually merging huge result sets when the platform provides a suitable feature.

Retrieval-Augmented Generation (RAG)

Vector search can retrieve context for an LLM. The retrieval layer remains a database access path, so the same authorization rules apply before generation occurs.

Security rules:

1. filter tenant/permissions during retrieval;
2. never rely on the model to hide unauthorized text;
3. treat retrieved documents as untrusted content;
4. apply prompt-injection defenses;
5. log carefully;
6. include source references where the product requires them.

Database authorization comes before generation. Retrieved text can contain instructions intended to manipulate the model, and a model is not a security boundary.

Vector data cost

Embeddings consume storage and indexing memory. Millions of high-dimensional vectors can be significant, and the cost includes both the database resources and the embedding provider's processing cost.

Measure:

• index size;
• query latency;
• ingestion rate;
• model embedding cost;
• reindex cost.

Do not add a vector field to every document without a product need. Keep derived data where it improves a real retrieval workflow and account for refresh and deletion behavior.

Search consistency

Search indexes may have synchronization delay relative to database writes. After a write, an ordinary MongoDB query may see the new value while Search briefly returns the old value.

Do not use a Search index for a strongly consistent authorization or financial existence check. Use an ordinary Mongo query for authoritative state. Search is a retrieval system, not the source of truth for transactional decisions.

This separation often leads to a two-step request: retrieve candidate identifiers through Search, then read authoritative records through MongoDB when the response requires current state or an authorization decision. The extra read is intentional; it preserves the consistency guarantee instead of hiding index lag.

Search pagination

Search supports specialized pagination mechanisms. Do not use deep $skip through relevance results, because large offsets can require unnecessary work and can be unstable as the result set changes.

Use search-after or search-before style APIs where supported. Choose a cursor strategy that matches the Search product and the user experience.

Specialized workload decision table

Do not solve every problem with aggregation. Aggregation is valuable, but it is not a substitute for a stream consumer, a time-series storage model, object storage, a geospatial index, or a search subsystem.

Failure clinic

Time-series + change stream assumed supported

Wrong feature combination. Verify collection-specific limitations before committing to an event-driven architecture.

GridFS for public images without considering object storage/CDN

Cost/performance mismatch. Public media often benefits from object-storage lifecycle features, byte ranges, caching, and edge delivery.

geo coordinates reversed

Wrong locations. Check GeoJSON order: longitude first, latitude second, and test with known points.

regex used as search engine

Slow or poor relevance. A regular expression may be adequate for a small, constrained query, but it is not automatically a scalable full-text or autocomplete design.

vector query lacks tenant filter

Security breach. Authorization must constrain retrieval itself, not be applied only to the returned list.

search result treated as authoritative latest state

Index lag problem. Use the ordinary collection for authoritative state.

embedding model changed without migration version

Index incompatibility. Record the model and migrate vectors and indexes deliberately.

change-stream token stored before side effect

Potential lost event. Persist progress only at a boundary that makes retry behavior safe.

Exercises

1. Build a change-stream projection with idempotency.
2. Persist the resume token after durable processing.
3. Create a time-series collection for device readings.
4. Design raw/downsampled retention.
5. Stream a file into GridFS and compare it with an object-storage design.
6. Build a 2dsphere nearest-place query.
7. Design a MongoDB Search index for product name, description, and autocomplete.
8. Design a vector document with a tenant filter.
9. Plan an embedding-model migration.
10. Threat-model a RAG search endpoint.
11. Explain which specialized features cannot be combined on time-series collections.

These exercises move from implementation to architecture and threat modeling. For each one, record the assumption that makes the feature appropriate and the failure you would look for if the assumption stopped being true.

When you review an implementation, ask where the authoritative state lives, where derived state can lag, and what happens after a retry. Those questions apply across streams, time-series summaries, file metadata, geospatial results, and search results.

Also check the operational boundary: which index or worker must be monitored, which data can be rebuilt, and which data must be backed up as a source of truth. This turns feature selection into an architecture decision rather than a syntax exercise.

Mastery checklist

Explain:

• change-stream resume/idempotency;
• time-series model/limits;
• GridFS/object storage trade-off;
• geospatial indexes;
• classic text versus Search;
• Search indexes;
• Vector Search;
• hybrid/RAG security;
• search consistency;
• specialized feature selection.

Official references

• https://www.mongodb.com/docs/manual/changeStreams/
• https://www.mongodb.com/docs/manual/core/timeseries-collections/
• https://www.mongodb.com/docs/manual/core/gridfs/
• https://www.mongodb.com/docs/manual/geospatial-queries/
• https://www.mongodb.com/docs/search/
• https://www.mongodb.com/docs/atlas/atlas-vector-search/

Additional specialized-feature depth: lifecycle and architecture boundaries

Specialized indexes and streaming features introduce their own lifecycle. Creating a query is only the beginning; production work also includes building, monitoring, migrating, scaling, and recovering the subsystem.

Search/vector index lifecycle

You need:

create index
initial build
monitor sync
deploy query
change mapping/model
rebuild new index
switch traffic
remove old

Do not edit a production index or model and hope every query remains compatible. Mapping changes, embedding changes, and query changes should be treated as versioned deployment work.

For major search changes, version the index name:

products_search_v1
products_search_v2

Build v2, validate its results and operational behavior, then switch traffic. Remove the old index only after rollback is no longer needed and its resource cost is understood.

Validation should cover more than whether the index builds. Compare representative relevance results, autocomplete behavior, filtered queries, synchronization delay, latency, and resource consumption. A mapping that improves one query can make another query slower or less precise.

Embedding lifecycle

Vector data is derived. Store enough metadata to reproduce or diagnose it:

{
  embedding: [...],
  embeddingModel:
    "model-2026-08",
  embeddedAt:
    new Date(),
  sourceHash:
    "sha256..."
}

When the source changes, the embedding becomes stale. A background worker detects the change and recomputes the vector. Do not recalculate an embedding synchronously on every read; that adds latency and makes ordinary reads dependent on an expensive derived-data operation.

Vector filtering before retrieval

The permission filter must be supported by the vector index and its filter fields. If the user is allowed to see only project P1:

filter projectId=P1
inside vector search

not:

retrieve top 10 global
remove unauthorized

Filtering after retrieval can:

• return zero useful results;
• leak timing or metadata;
• violate least exposure.

The security issue is not fixed by requesting a larger global result set. Retrieval itself must operate within the user's allowed scope.

Test this with documents that are semantically very close but belong to different tenants or projects. A correct implementation should never need to retrieve a forbidden document in order to discard it later.

Change-stream scaling

One change stream per request or client is expensive. For many users, use a small number of backend consumers and fan out the relevant application events:

one/few backend consumers
→ internal pubsub
→ WebSocket/SSE clients

At multi-instance scale, pubsub may need Redis, NATS, Kafka, or another suitable system. The browser connection count should not determine the number of MongoDB change streams.

Do not open 100k Mongo change streams because 100k browser clients are connected. Centralize database consumption, then design client fanout and reconnection behavior separately.

Change-stream partition/order

Ordering is defined by change-stream and topology semantics, but consumers should not invent a total business order across unrelated entities if it is not required.

For a per-aggregate workflow, use:

version
sequence
event timestamp

and idempotency. Define the ordering contract at the aggregate boundary where the business actually needs one instead of imposing an expensive global ordering requirement.

GridFS range downloads

Large-media clients may request byte ranges. GridFS stream APIs are not automatically CDN-grade media serving.

Object storage and a CDN handle these concerns better for many media workloads:

• range;
• caching;
• edge;
• signed URLs.

If the product needs frequent public or semi-public media delivery, compare that architecture before building a custom GridFS range-serving layer.

Time-series meta cardinality

If the meta field is unique for every measurement:

meta:
{
  requestId:
    randomUUID()
}

bucketing cannot group effectively. Meta should represent stable series identity, not a value that changes with every event. A request identifier may belong in the measurement document, but it is usually a poor series key.

Geospatial + tenant

Compound geospatial index patterns have restrictions and order considerations. For multi-tenant places, design the query and index according to the current MongoDB geospatial compound-index rules.

Do not omit tenant security just because $near query syntax is specialized. Confirm that the tenant constraint is enforced by the query and that the chosen index supports the actual access pattern.

Search index lag UX

After a product is updated:

normal Mongo detail shows new title
search may show old title briefly

The UI can:

• accept eventual search;
• invalidate or locally update;
• show authoritative detail on click.

Document the consistency behavior so users understand why a detail page and a result card can briefly disagree. Do not hide the distinction by treating Search as authoritative.

The same documentation should state what the client does during the lag window. Clear behavior is easier to support than an implicit promise that every search result is immediately current.

Additional exercises

1. Version a Search index and plan a zero-downtime switch.
2. Design an embedding refresh worker using a source hash.
3. Ensure the vector filter contains tenant or project scope.
4. Replace one-change-stream-per-client with a backend fanout architecture.
5. Compare GridFS versus object storage for video.
6. Fix a high-cardinality time-series meta design.
7. Design UX for search-index lag.

Production mastery check

Specialized Mongo features should be treated as subsystems with indexing, consistency, scaling, and recovery behavior, not one-line query operators.

That framing gives you a practical review sequence:

• identify the source of truth;
• identify derived or eventually consistent state;
• identify the index and its lifecycle;
• identify retry and recovery behavior;
• identify tenant and permission boundaries;
• measure cost and latency at expected scale.

If those answers are missing, the feature choice is not finished, even when the first query works.