데이터베이스 트리거: CRUD 이벤트에 반응하기

Atlas Database Triggers are serverless event handlers that automatically execute an Atlas Function whenever a specific CRUD event (insert, update, replace, delete) occurs on a collection. They are built on top of MongoDB Change Streams and eliminate the need to run a polling process or manage infrastructure for event-driven workflows.

Internally, Atlas triggers use a change stream that MongoDB opens on the target collection. Every matching change event is forwarded to the trigger, which invokes the associated Atlas Function with the event document as its argument. The function runs in Atlas's managed JavaScript runtime — no servers to provision or scale. Triggers can handle up to hundreds of events per second with auto-scaling.

When configuring a database trigger you specify: Cluster name and collection to watch. Operation types to react to: insert, update, replace, delete, or any combination. Full Document option — when enabled, MongoDB fetches the complete document after the change and includes it in the event payload. Linked Function — the Atlas Function to invoke.

The event document passed to the trigger function has these key fields: operationType ('insert', 'update', 'replace', 'delete'), fullDocument (the document after the change, if enabled), documentKey (the _id of the changed document), updateDescription (for updates: which fields were set or unset), and ns (database and collection namespace).

A trigger function is an Atlas Function — server-side JavaScript that has access to the context object (MongoDB client, services, user info) and receives the change event as its first argument. Here is a pattern for handling new orders: send a notification email and update an analytics counter.

You can add a match expression to a trigger so it only fires for a subset of events. This is implemented as an aggregation pipeline on the change stream. For example, only trigger on orders above a certain amount, only fire on updates where the status field changed, or only react to documents from a specific tenant.

For INSERT and REPLACE operations, fullDocument is always available in the change event. For UPDATE events, fullDocument is only available if you enable the Full Document option in the trigger config, which causes Atlas to perform an additional document lookup (a second read). Without it, only updateDescription (changed fields) is available.

If a trigger function throws an error or times out (maximum 90 seconds), Atlas automatically retries it up to 3 times with exponential backoff. After all retries fail, the event is logged as failed in the Atlas Trigger error log. You should write trigger functions to be idempotent — applying the function multiple times to the same event produces the same result — to handle retries safely.

A common use case is data synchronisation: when a document changes in one collection, a trigger propagates the change to a denormalised copy in another collection. For example, when a user's email changes in the users collection, a trigger updates the denormalised email field in every document in the orders collection that references that user.

By default, Atlas triggers process events sequentially in the order they arrive. If you enable event ordering off (in trigger settings), multiple function invocations can run in parallel for higher throughput — but then your function must be safe for concurrent execution. Sequential mode is safer; parallel mode is faster for high-event-rate collections.

You can enable or disable triggers at any time from the Atlas UI without deleting them. The Trigger Execution Log in Atlas shows each invocation: status (success/failure/timeout), duration, and error details. Use this log to debug failing triggers and monitor execution trends. Atlas also exposes trigger metrics in the Atlas Monitoring dashboard.

In this lesson you learned: Atlas Database Triggers fire an Atlas Function on insert/update/replace/delete events using a change stream internally, match expressions filter which events invoke the function, and functions must be idempotent because Atlas retries failed invocations automatically. Next up we explore scheduled triggers and cron jobs.