Does LatestVersion change feed mode notify handlers when a document is deleted?

Not as an explicit, distinct delete event by default, a deleted document simply stops appearing in subsequent LatestVersion change feed reads, there's no dedicated 'this was deleted' notification in that mode. If a handler genuinely needs to react to deletions (like removing a corresponding row in a materialized view), changeFeedMode needs to be set to AllVersionsAndDeletes, which does surface explicit delete events.

What happens if startFromBeginning is accidentally left true when adding a processor to a large, already-populated container?

The processor replays the container's entire change history through every configured handler starting from the very first ever change, for a large container, this can mean millions of historical events suddenly triggering Function invocations, Event Hub messages, and materialized view writes all at once, a potentially very expensive and disruptive one-time burst that's rarely the actual intent when adding a new processor to existing data.

Does the lease container need its own dedicated throughput, or can it share the monitored container's throughput?

It needs its own throughput allocation (as the example's leaseContainer.throughput: 400 shows), it's a genuinely separate container tracking per-partition processing checkpoints, not sharing the monitored container's provisioned RU/s. Under-provisioning lease container throughput for a high-partition-count monitored container can itself become a processing bottleneck, independent of the monitored container's own throughput.

Azure Cosmos DB Change Feed Builder

StorageAzure

Build Cosmos DB change feed processor configs with lease containers, handlers, dead-letter queues, and lag estimation.

Azure Cosmos DB Configuration

Build Cosmos DB change feed processor configs with lease containers, handlers, dead-letter queues, lag estimation, and event routing.

Required Fields

accountNamedatabaseNamemonitoredContainer.nameleaseContainer.namechangeFeedProcessor.processorNamechangeFeedMode

{
  "accountName": "cosmos-contoso-prod",
  "databaseName": "orders-db",
  "monitoredContainer": {
    "name": "orders",
    "partitionKey": "/customerId"
  },
  "leaseContainer": {
    "name": "orders-leases",
    "partitionKey": "/id",
    "createIfNotExists": true,
    "throughput": 400
  },
  "changeFeedProcessor": {
    "processorName": "orderEventProcessor",
    "instanceName": "instance-01",
    "startFromBeginning": false,
    "startTime": null,
    "maxItemCount": 100,
    "pollIntervalMs": 1000,
    "feedRange": null,
    "leaseAcquireInterval": "PT13S",
    "leaseExpirationInterval": "PT60S",
    "leaseRenewInterval": "PT17S"
  },
  "changeFeedMode": "LatestVersion",
  "handlers": [
    {
      "name": "OrderCreatedHandler",
      "filter": { "field": "eventType", "value": "OrderCreated" },
      "action": {
        "type": "FunctionTrigger",
        "functionAppName": "func-order-processor",
        "functionName": "OnOrderCreated"
      }
    },
    {
      "name": "OrderShippedHandler",
      "filter": { "field": "eventType", "value": "OrderShipped" },
      "action": {
        "type": "EventHubOutput",
        "eventHubNamespace": "evhns-contoso-prod",
        "eventHubName": "order-events",
        "partitionKey": "orderId"
      }
    },
    {
      "name": "MaterializedViewHandler",
      "filter": null,
      "action": {
        "type": "ContainerOutput",
        "targetDatabase": "analytics-db",
        "targetContainer": "order-summary",
        "upsert": true
      }
    }
  ],
  "errorHandling": {
    "deadLetterContainer": {
      "name": "change-feed-dead-letter",
      "partitionKey": "/sourceContainer",
      "ttlSeconds": 604800
    },
    "maxRetries": 3,
    "retryIntervalMs": 5000
  },
  "estimator": {
    "enabled": true,
    "estimationIntervalMs": 5000,
    "metricName": "ChangeFeedLag"
  }
}

Generated Output

Output will appear here...

What This Tool Does

Build a Cosmos DB change feed processor configuration with a dedicated lease container tracking processing progress per partition, multiple handlers routing different event types to different destinations (Function trigger, Event Hub, or a materialized-view container), and changeFeedMode set to LatestVersion (the default, seeing only the current state after each change) versus AllVersionsAndDeletes (a newer mode that also surfaces intermediate versions and delete events explicitly). startFromBeginning: false means a newly-deployed processor only sees changes from the moment it starts, not the container's entire existing history, which is almost always the right choice for an already-populated production container, since replaying the entire history through every handler (including one writing to Event Hub or triggering a Function per event) could be a massive, unintended one-time processing burst.

Technical Details

The builder validates that accountName, databaseName, monitoredContainer.name, leaseContainer.name, changeFeedProcessor.processorName, and changeFeedMode all resolve before accepting the JSON as a valid combined change feed processor specification; it can't verify the referenced Function app, Event Hub, or target container destinations actually exist and are reachable, those are only confirmed once the processor actually starts running and attempts to deliver events.

Common Use Cases

1Setting changeFeedMode to AllVersionsAndDeletes specifically when a handler needs to react to delete events (LatestVersion mode's change feed doesn't surface deletes as distinct events by default, a deleted document simply stops appearing), essential for the MaterializedViewHandler pattern to correctly remove entries when source documents are deleted.
2Routing different eventType-filtered handlers to different destinations (OrderCreatedHandler to a Function, OrderShippedHandler to an Event Hub) from the same underlying change feed, avoiding the need for separate change feed processors per downstream consumer.
3Configuring a deadLetterContainer with a bounded ttlSeconds, so an event that repeatedly fails processing (after maxRetries) lands somewhere inspectable and self-cleaning, rather than blocking the processor indefinitely or being silently dropped.
4Setting startFromBeginning to false for a processor being added to an already-populated container, avoiding an unintended full-history replay burst through every configured handler the moment the processor first starts.

Common Questions

Does LatestVersion change feed mode notify handlers when a document is deleted?: Not as an explicit, distinct delete event by default, a deleted document simply stops appearing in subsequent LatestVersion change feed reads, there's no dedicated 'this was deleted' notification in that mode. If a handler genuinely needs to react to deletions (like removing a corresponding row in a materialized view), changeFeedMode needs to be set to AllVersionsAndDeletes, which does surface explicit delete events.
What happens if startFromBeginning is accidentally left true when adding a processor to a large, already-populated container?: The processor replays the container's entire change history through every configured handler starting from the very first ever change, for a large container, this can mean millions of historical events suddenly triggering Function invocations, Event Hub messages, and materialized view writes all at once, a potentially very expensive and disruptive one-time burst that's rarely the actual intent when adding a new processor to existing data.
Does the lease container need its own dedicated throughput, or can it share the monitored container's throughput?: It needs its own throughput allocation (as the example's leaseContainer.throughput: 400 shows), it's a genuinely separate container tracking per-partition processing checkpoints, not sharing the monitored container's provisioned RU/s. Under-provisioning lease container throughput for a high-partition-count monitored container can itself become a processing bottleneck, independent of the monitored container's own throughput.

Expert Tips

TIP

Verify changeFeedMode matches what your handlers actually need, a handler relying on explicit delete events (like the materialized view pattern) silently misses deletions entirely under the default LatestVersion mode, this is a common and non-obvious gap.

TIP

Always set startFromBeginning deliberately, not by accepting a default, adding a new processor to existing production data with this set to true (or the platform default, if different) can trigger a massive, expensive replay burst through every configured handler.

TIP

Size the dead-letter container's ttlSeconds to match how long a failed event is actually worth investigating, an indefinite TTL means the dead-letter container grows without bound if failures aren't actively triaged and cleared.

Related Learning Guides

Storage Account Types22 min read
Cosmos DB Consistency Levels24 min read

Was this tool helpful?

Disclaimer: This tool runs entirely in your browser. No data is sent to our servers. Always verify outputs before using them in production. AWS, Azure, and GCP are trademarks of their respective owners.