(DOCSP-34109) Trigger Throughput Wording

source/triggers.txt

@@ -29,7 +29,7 @@ can respond to events or use pre-defined schedules.
 Triggers listen for events of a configured type. Each Trigger links to a
 specific :doc:`Atlas Function </functions>`.
 When a Trigger observes an event that matches your
-configuration, it *"fires."* The Trigger passes this event object as the
+configuration, it *"fires"*. The Trigger passes this event object as the
 argument to its linked Function.
 
 A Trigger might fire on:
@@ -39,7 +39,7 @@ A Trigger might fire on:
 - A scheduled time.
 
 App Services keeps track of the latest execution time for each
-Trigger.
+Trigger and guarantees that each event is processed at least once.
 
 .. _trigger-types:
 
@@ -76,26 +76,34 @@ constraints as all Atlas Functions.
 Event Processing Throughput
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
-Trigger events are added to a queue and processed when capacity becomes
-available. The rate at which a Trigger processes events depends on the
-Trigger's configuration as well as the logic in the Trigger function.
+Triggers process events when capacity becomes available. A Trigger's
+capacity is determined by its event ordering configuration:
 
-Ordered triggers process events from the queue one at a time. An
-unordered trigger can process up to 10,000 events concurrently.
+- Ordered triggers process events from the change stream one at a time
+  in sequence. The next event begins processing only after the previous
+  event finishes processing.
 
-.. note::
+- Unordered triggers can process multiple events concurrently, up to
+  10,000 at once by default. If your Trigger data source is an M10+
+  Atlas cluster, you can configure individual unordered triggers to
+  exceed the 10,000 concurrent event threshold. To learn more, see
+  :ref:`Maximum Throughput Triggers <triggers-maximum-throughput>`.
 
-   If the linked data source is a dedicated server (M10+ Tier), 
-   you can configure individual triggers to process up to 50,000 events concurrently.
+Trigger capacity is not a direct measure of throughput or a guaranteed
+execution rate. Instead, it is a threshold for the maximum number of
+events that a Trigger can process at one time. In practice, the rate at
+which a Trigger can process events depends on the Trigger function's run
+time logic and the number of events that it receives in a given
+timeframe.
 
 To increase the throughput of a Trigger, you can try to:
 
-- Optimize the Trigger function's run time. For example, you might
-  reduce the number of network calls that you make.
+- Optimize the Trigger function's run time behavior. For example, you
+  might reduce the number of network calls that you make.
 
-- Reduce the size of each event object with the Trigger's projection
-  filter. For the best performance, we recommend limiting the size of
-  each change event to 2KB or less.
+- Reduce the size of each event object with the Trigger's
+  :ref:`projection filter <trigger-project-expression>`. For the best
+  performance, limit the size of each change event to 2KB or less.
 
 - Use a match filter to reduce the number of events that the Trigger
   processes. For example, you might want to do something only if a

source/triggers/database-triggers.txt

@@ -350,7 +350,9 @@ options are available:
 
    * - :guilabel:`Project Expression`
 
-     - .. include:: /includes/trigger-project-expression.rst
+     - .. _trigger-project-expression:
+
+       .. include:: /includes/trigger-project-expression.rst
 
    * - :guilabel:`Auto-Resume Triggers`
 
@@ -360,9 +362,9 @@ options are available:
 
      - .. _triggers-maximum-throughput:
 
-       If the linked data source is a dedicated server (M10+ Tier), 
+       If the linked data source is a dedicated server (M10+ Tier),
        you can increase the :ref:`maximum throughput <event_processing_throughput>`
-       from the default 10,000 concurrent processes to 50,000. 
+       beyond the default 10,000 concurrent processes.
 
        .. important::
 
@@ -763,12 +765,13 @@ Consider disabling event ordering if your trigger fires on a collection that
 receives short bursts of events (e.g. inserting data as part of a daily batch
 job).
 
-Ordered Triggers wait to execute a Function for a particular event until the
-Functions of previous events have finished executing. As a consequence,
-ordered Triggers are effectively rate-limited by the run time of each
-sequential Trigger function. This may cause a significant delay between the
-database event and the Trigger firing if a sufficiently large number of
-Trigger executions are currently in the queue.
+Ordered Triggers wait to execute a Function for a particular event until
+the Functions of previous events have finished executing. As a
+consequence, ordered Triggers are effectively rate-limited by the run
+time of each sequential Trigger function. This may cause a significant
+delay between the database event appearing on the change stream and the
+Trigger firing. In certain extreme cases, database events might fall off
+the oplog before a long-running ordered trigger processes them.
 
 Unordered Triggers execute functions in parallel if possible, which can be
 significantly faster (depending on your use case) but does not guarantee that