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.

Primary references

• Amazon Builders’ Library — Making retries safe with idempotent APIs
• AWS Prescriptive Guidance — Transactional outbox pattern
• PostgreSQL documentation — Constraints
• OpenTelemetry — Context propagation

An infrastructure dashboard often makes a subtle modelling mistake: it stores a value and a unit, then loses the question the value answers. A field called capacity_mw might refer to a utility request, electrical input to a building, IT equipment or a heat-removal duty. Sorting that column produces a neat table, but not necessarily a meaningful comparison. Treating quantities as typed records makes the missing context visible.

1. Separate a rate from an accumulated quantity

NIST distinguishes energy, measured in joules, from power, measured in watts: joules per second. In common infrastructure reporting, MW describes a power level and MWh an energy amount. A constant illustrative load of 1 MW over two hours uses 2 MWh at the same measurement boundary. This arithmetic does not reveal the peak load, equipment rating or connection permission.

For a varying load, the energy amount depends on how the power changes throughout the interval. Dividing an annual energy total by elapsed hours gives an average, not a confirmed maximum. Berkeley Lab’s 2026 report makes the wider problem explicit: IT nameplate capacity, requested grid capacity and annual electricity consumption cannot be interchanged without additional information.

2. Make the physical boundary part of the type

A practical record should include quantity, unit, physical kind, boundary, time basis and evidence state. The following is an instructional example, not IAG facility data:

{
  "value": 1,
  "unit": "MW",
  "kind": "electrical_power",
  "boundary": "facility_input",
  "basis": "illustrative_constant_load",
  "duration_hours": 2
}

A separate record for requested connection capacity should carry its own boundary and status. Do not relabel it as available operating capacity because the numeric value is unchanged. Likewise, preserve whether a figure is a proposal, an equipment rating or an operating measurement. These labels are part of the data contract, not optional notes that disappear during export.

3. Distinguish heat-removal duty from electrical input

The watt is also a unit of heat-flow rate. Two quantities marked kW can therefore describe different things: heat transferred by a cooling system and electricity consumed to run it. A unit check alone cannot tell them apart. Add a physical-kind field and identify the equipment or interface being measured.

DOE’s design guide treats cooling performance separately from whole-facility energy metrics. Its water-efficiency guidance also illustrates how heat can move through several circuits before being rejected outdoors. A label such as liquid cooling describes part of that arrangement; it is not a substitute for the boundary of the recorded quantity.

4. Carry the reporting interval into each ratio

Annual PUE compares total facility energy with IT equipment energy over the reporting period. Site WUE compares annual site water use with IT equipment energy, in litres per kilowatt-hour. Their numerators measure different resources. Neither should be stored as an unexplained efficiency percentage.

Keep numerator and denominator totals, period, coverage and calculation method alongside the ratio. Distinguish a design estimate from a measured annual result. An annual PUE is not, by itself, a verified multiplier for converting a peak IT rating into required grid capacity: that calculation needs compatible boundaries and stated operating assumptions.

5. Reject incompatible comparisons before drawing a chart

A comparison routine can require matching physical kind and boundary, compatible reporting periods, consistent units and an explicitly accepted evidence state. Missing fields should produce an unresolved comparison, not a guessed conversion. Unit conversion can transform a known quantity; it cannot supply a missing connection agreement or measurement scope.

This approach also improves the explanation beside a chart. Readers can see whether they are comparing equipment designs, utility requests or recorded operation. The result is a more honest data product, not a claim that a particular facility has been qualified. The examples here are generic engineering proposals; they do not report IAG-owned capacity or measured operating performance.

Primary references

• NIST — Guide to the SI, Chapter 4: derived quantities and units
• Lawrence Berkeley National Laboratory — United States Data Center Energy Usage Report: 2025 Update (June 2026)
• DOE/FEMP — Best Practices Guide for Energy-Efficient Data Center Design (revised July 2024)
• DOE/FEMP — Cooling Water Efficiency Opportunities for Federal Data Centers (9 January 2019)