Company editorial by Infrastructure Assets Group LLC
A customer chooses a package, submits a question and opens an AI adviser. Behind that short journey, a website, CRM and conversation service may each have their own database and failure modes. A successful HTTP response from one component does not establish that the entire handoff completed. The engineering problem is to preserve one business request while allowing transport, processing and display to recover independently.
Give the business request an identity of its own
Separate the original submission identifier from a delivery-attempt identifier and a tracing identifier. The submission remains stable when a response is lost. A delivery identifies a transport attempt. A trace helps investigate execution. Using the trace ID as the business deduplication key confuses observability with the lifetime of the customer’s intent.
Store the accepted package reference and the relevant version or snapshot with that intent. A later catalogue change should not silently rewrite what the original question referred to. AWS’s idempotent-API guidance describes a related distinction: reuse of an existing request identifier with different parameters should not be treated as the same operation.
Commit acceptance and delivery intent together
Where the website owns the initial submission, write its accepted record and an outbound event in one local transaction. A separate dispatcher can deliver committed events. This avoids the dual-write gap where the database succeeds but the notification never leaves, or the notification leaves before the database transaction fails.
AWS documents this as the transactional outbox pattern. It also warns that messages can still be duplicated. An outbox is a durable handoff mechanism, not a promise that the receiving system will see each event only once. Preserve event identity and use bounded, policy-appropriate delivery recovery rather than creating a new customer request.
Make the CRM acknowledge a canonical result
On receipt, resolve the customer through an explicit mapping and validate the original submission reference. Use a database-enforced key for duplicate detection, then commit the accepted event and resulting canonical record together. PostgreSQL’s constraint documentation illustrates composite uniqueness; non-null identity fields matter because nullable unique columns can have surprising semantics.
-- Illustrative fragment, not a migration for any deployed system.
source_system TEXT NOT NULL,
submission_id TEXT NOT NULL,
UNIQUE (source_system, submission_id)
Return a receipt pointing to the committed record. Receiving bytes, validating an event and committing an inquiry are different states; the website should display the state actually acknowledged. A duplicate with identical intent can return the original receipt. A mismatched reuse needs an explicit refusal, not an overwrite.
Build adviser context from the accepted record
The adviser should read a defined projection of the canonical inquiry: the customer mapping, selected package context, original question and permitted conversation history. Keep source version and freshness with the projection. A browser’s current dropdown is useful interface state, but should not replace the server’s accepted context for an earlier request.
Keep the response attached to the original inquiry and conversation. A model-generated explanation is separate from a CRM mutation or an executed action. When required context is missing or stale, expose that condition instead of implying that a generic answer used the customer’s accepted package.
Recover the display without inventing another submission
After refresh, load the original receipt and conversation before enabling another send. A timeout can leave the caller uncertain even when the receiver committed successfully. Reconcile that original outcome through its supported status path; changing the key merely to make a retry appear new defeats deduplication.
OpenTelemetry context propagation can connect the website, dispatcher and CRM spans for diagnosis. Keep that correlation separate from business authority, and avoid placing private conversation content in tracing baggage. Observe acceptance with concrete outcomes: one inquiry, the intended package context, the retained answer and stable history after reload. This is a generic architecture explainer, not a claim that IAG’s platform has completed deployment, benchmarking or independent assurance.
Top comments (0)