Atomicity treats a multi-step operation as one indivisible unit: every effect applies, or none does. This prevents partial success from leaving resources inconsistent and keeps result handling predictable. section 18.1 section 18.3.1
Apply atomicity deliberately across API designs:
- Treat list-valued fields as atomic data: replace the entire list rather than updating an item by position or through a second endpoint. section 5.6.1
- Use batch methods when several resources must succeed or fail together; do not expose partial-success responses when all-or-nothing behavior is the goal. section 18.3 section 18.3.1
- Recognize isolation trade-offs: separating a singleton sub-resource can protect focused or sensitive data while making parent-and-sub-resource updates non-atomic. section 12.4.1
- For copy operations, use a point-in-time snapshot, a transaction, or write locking when consistency requires one view of the source data. section 17.3.6
Enabling a default logging configuration
Suppose a ChatRoom logging configuration must be enabled before it can become the default. Exposing separate requests to enable the configuration and assign it as default permits an invalid intermediate state. A transaction-like or batch operation should make both changes succeed together or leave both unchanged. section 18.1
Do not assume individually atomic requests become collectively atomic. Choose one authoritative update path for shared data, define complete-success responses, and accept weaker consistency only when storage or uptime constraints make stronger guarantees unavailable. section 5.6.1 section 17.3.6
