Integration Patterns 2026: Command Patterns (Writes, Idempotency, Consistency)

I started the year using Gemini Pro to take our integration patterns and covert them into “playing card” style pattern library so that we can print and play! The content is mine, I used AI to generate the images with still a few issues with image text – oh well, maybe something to refine later in 2026 or next year. In this post we explore writes where we must deal with duplicates, retries, and partial failures as key design and architectural challenges. Using these we look at pros and cons to make writes safe under failure and concurrency.

Included patterns

• CP-1 — Real-time Consistent Synchronous Write to Master
• CP-2 — Real-time Consistency Asynchronous Write to Master
• CP-3 — Buffered Write (Delayed Consistency)
• CP-4 — Shopping-cart / Draft Copy
• CP-5 — High-Available Shallow Copy + Later Sync
• CP-6 — Dual-copy Sync

CP-1: Real-time Consistent Synchronous Write to Master

Synchronous create/update; API returns only after the master transaction commits.

When to use

• Client needs immediate confirmation and canonical ID.
• Single-entity or parent-child write fits in one transaction.
• Client can handle validation errors inline.

Pros

• Immediate correctness.
• Simple for clients.
• Good for transactional UX flows.

Cons

• Higher latency.
• Tight runtime coupling; failures cascade.
• Can throttle master under burst writes.

PlantUML

@startuml
title Real-time Consistent Synchronous Write to Master
actor "Client" as Client
participant "API/BFF" as API_BFF
participant "Master System" as Master_System
Client -> API_BFF: POST/PUT /resource (payload)
API_BFF -> Master_System: Validate + write (transaction)
Master_System -> API_BFF: 201/200 + canonicalId
API_BFF -> Client: 201/200 + canonicalId
@enduml

CP-2: Real-time Consistency Asynchronous Write to Master

API accepts command and acknowledges before the master is consistent; backend completes later and may emit status events.

When to use

• Master write is workflow-driven or long-running.
• You need fast acknowledgement to the client.
• Client can handle eventual completion and status tracking.

Pros

• Decouples client from master latency.
• Better availability under load.
• Supports long-running workflows.

Cons

• Client must manage pending state.
• Requires status model (submissionId).
• Duplicates/retries need idempotency.

PlantUML

@startuml
title Real-time Consistency Asynchronous Write to Master
actor "Client" as Client
participant "API/BFF" as API_BFF
participant "Command Queue/Stream" as Command_Queue_Stream
participant "Worker" as Worker
participant "Master System" as Master_System
Client -> API_BFF: POST/PUT command
API_BFF -> Command_Queue_Stream: Enqueue command
API_BFF -> Client: 202 Accepted (submissionId)
Worker -> Command_Queue_Stream: Consume command
Worker -> Master_System: Apply change
Master_System -> Worker: Success/Failure
@enduml

CP-3: Buffered Write (Delayed Consistency)

High-volume commands are buffered in a queue/stream to protect the master; processed asynchronously in controlled batches.

When to use

• High-volume inbound writes (bulk uploads).
• Client does not need immediate canonical ID.
• Master must be protected from spikes.

Pros

• Smooths bursts; protects master.
• Enables back-pressure and rate limiting.
• Improves resilience.

Cons

• Eventual consistency.
• Operational complexity (queues, DLQ).
• Need strong idempotency + replay controls.

PlantUML

@startuml
title Buffered Write (Delayed Consistency)
actor "Client" as Client
participant "Ingress API" as Ingress_API
participant "Buffer (Kafka/Queue)" as Buffer__Kafka_Queue_
participant "Bulk Processor" as Bulk_Processor
participant "Master System" as Master_System
Client -> Ingress_API: Upload/command batch
Ingress_API -> Buffer__Kafka_Queue_: Append write log
Ingress_API -> Client: 202 Accepted (jobId)
Bulk_Processor -> Buffer__Kafka_Queue_: Consume in batches
Bulk_Processor -> Master_System: Apply changes (rate-limited)
Master_System -> Bulk_Processor: Ack/Errors
@enduml

CP-4: Shopping-cart / Draft Copy

Draft state is stored near the consumer (BFF/local DB) and only the final submitted record is sent to the master.

When to use

• Users iteratively build a large request (forms, applications).
• Master only accepts full records, not partial updates.
• You want resilience while users edit over time.

Pros

• Great UX (save/resume).
• Reduces partial writes to master.
• Works well with validation and review steps.

Cons

• Dual state to reconcile.
• Draft retention and privacy concerns.
• Submit step needs strong validation/versioning.

PlantUML

@startuml
title Shopping-cart / Draft Copy
actor "Client" as Client
participant "BFF/Draft Service" as BFF_Draft_Service
participant "Draft Store" as Draft_Store
participant "Master System" as Master_System
Client -> BFF_Draft_Service: Save draft changes
BFF_Draft_Service -> Draft_Store: Upsert draft
Client -> BFF_Draft_Service: Submit draft
BFF_Draft_Service -> Master_System: Create/Update full record
Master_System -> BFF_Draft_Service: CanonicalId + status
BFF_Draft_Service -> Client: Submission result
@enduml

CP-5: High-Available Shallow Copy + Later Sync

Write first to a highly available local store (shallow copy), return quickly, then synchronise to master later (small sets or batch).

When to use

• Front-end requires high availability and low latency writes.
• Master is slow/unavailable intermittently.
• Shallow copy is sufficient for immediate downstream usage.

Pros

• High availability at the edge.
• Continues operating during master outages.
• Supports offline/poor connectivity.

Cons

• Conflict resolution required.
• Sync pipeline and reconciliation needed.
• Risk of diverging truths if governance is weak.

PlantUML

@startuml
title High-Available Shallow Copy + Later Sync
actor "Client" as Client
participant "Edge API" as Edge_API
participant "HA Shallow Store" as HA_Shallow_Store
participant "Sync Worker" as Sync_Worker
participant "Master System" as Master_System
Client -> Edge_API: POST/PUT (payload)
Edge_API -> HA_Shallow_Store: Write shallow copy
Edge_API -> Client: 202/201 (tempId/ack)
Sync_Worker -> HA_Shallow_Store: Read pending changes
Sync_Worker -> Master_System: Upsert canonical record
Master_System -> Sync_Worker: CanonicalId/Status
@enduml

CP-6: Dual-copy Sync

Maintain a shallow or partial copy in a highly available system, then synchronise to master in batches or small sets.

When to use

• Immediate availability and responsiveness is required.
• Later synchronisation is acceptable and governed.

Pros

• Same as shallow copy: availability, resilience.
• Allows local optimisation for UX and caching.

Cons

• Same as shallow copy: conflicts and reconciliation.
• More complex testing across two stores.

PlantUML

@startuml
title Dual-copy Sync
actor "Client" as Client
participant "Local Service" as Local_Service
participant "Local Store" as Local_Store
participant "Batch Sync" as Batch_Sync
participant "Master System" as Master_System
Client -> Local_Service: Write request
Local_Service -> Local_Store: Commit locally
Local_Service -> Client: Ack (local)
Batch_Sync -> Local_Store: Extract changes
Batch_Sync -> Master_System: Sync batch
Master_System -> Batch_Sync: Ack/Errors
@enduml

Summary

We explored write patterns in this post, see related posts for reads, data patterns and AI patterns. Now before we implement writes we must remember to

• Define the contract first (schema, idempotency key, ordering expectations)
• Make retries safe (idempotent handlers, dedupe, at-least-once assumptions)
• Prefer explicit staleness windows over implicit “eventually consistent” windows for obvious reasons
• Instrument job state and failure modes (metrics + searchable logs) because operability is always a key software quality

Let me hear from you:

What is your favourite pattern? Have you composed simple integration patterns in a more complex end to end solution pattern? What were/are your key challenges?