Serverless Edge Gateway and CAPI Architecture: Fast Destinations, Reliable Event Deduplication

The gateway must preserve both speed and the truth of the offer

An enterprise campaign destination has two distinct responsibilities: present the advertised offer accurately and record eligible business events reliably. A fast redirect cannot repair a misleading offer, and an accepted conversion event does not prove that a purchase occurred. At $10,000 to $50,000 in daily spend, those distinctions become operating controls. The engineering objective is a consistent customer journey with timely, traceable measurement and an auditable connection to real commercial outcomes.

The gateway must not identify reviewers to show them a different commercial offer. Google's published policy prohibits cloaking intended to hide noncompliance, while distinguishing legitimate localization and appropriate tracking redirects from deception. That distinction is a useful release principle across the agency's destination estate: the advertised product and material conditions must remain truthful and reviewable. Faster delivery should improve the same offer that customers actually receive. [S1](https://support.google.com/adspolicy/answer/15938075?hl=en)

Define the measurement contract before writing the transport

Begin with the business event. A completed purchase should correspond to an actual order state defined by the merchant, not merely a visit to a thank-you page. A lead should correspond to the agreed submission milestone and should not automatically be counted as qualified revenue. If a sweepstakes entry is the event, label it accordingly and preserve the distinction between entry, marketing permission, downstream qualification, and any eventual sale.

Create a contract containing event name, durable occurrence identifier, occurrence time, destination dataset, authorized tenant, relevant value and currency, permitted fields, and dispatch eligibility. Specify which system is authoritative for each field. The browser can report that a button was clicked, but it should not be the sole authority for a paid order's value or settlement status. Validate business facts against the system that actually records the transaction.

Meta's public developer documentation identifies event name and event identifier as inputs to deduplicating browser and server events. The browser's event identifier and the server's corresponding identifier must agree for the same occurrence. That requirement supports a simple design principle: establish identity once and reuse it across delivery paths. It does not mean every event with a similar timestamp or customer email will be treated as the same occurrence. [S2](https://developers.facebook.com/documentation/ads-commerce/conversions-api/deduplicate-pixel-and-server-events)[S3](https://developers.facebook.com/documentation/ads-commerce/conversions-api/parameters/server-event)

Scope identifiers to the occurrence and the tenant

A durable occurrence identifier should survive network retries and page reloads associated with the same business action. Generate or assign it when the authoritative action is recorded, then carry it into the approved browser and server representations. A new purchase receives a new identifier even if the customer and product are unchanged. A retransmission of the existing purchase keeps its original identifier and occurrence time.

Internally, key the delivery record by tenant, destination, event name, and occurrence identifier. This prevents one client's identifier from colliding with another client's event. Use an unambiguous encoding rather than concatenating user-controlled strings with an unsafe separator. External identifiers should be opaque and should not embed email addresses, phone numbers, or sensitive order contents. A stable reference is useful without turning a tracking field into a disclosure channel.

type EventIdentity = {
  tenantId: string;
  destinationId: string;
  eventName: string;
  occurrenceId: string;
};

function deliveryKey(x: EventIdentity): string {
  const fields = [x.tenantId, x.destinationId, x.eventName, x.occurrenceId];
  if (fields.some(v => v.trim().length === 0)) throw new Error('Missing identity field');
  return JSON.stringify(fields);
}
// Internal key only; keep the approved external event identifier stable on retries.

This example establishes deterministic identity; it does not implement authentication, persistence, or a complete platform payload. A production adapter must validate the current destination contract and enforce tenant authorization separately. The server should select the destination from approved configuration, not trust a browser-supplied account identifier. Otherwise, an attacker or configuration mistake could route one client's commercial events into another client's measurement system.

Make a sub-600-millisecond objective measurable

A latency target needs a start event, an end event, a population, and a percentile. For this design, define gateway response latency as the time from receipt of a valid request at the gateway to completion of its routing response. Separately measure browser navigation latency from the initial click to a usable destination. A gateway that responds in fifty milliseconds can still lead to a slow page because of network, connection, download, and rendering costs.

For an illustrative serial navigation budget, allocate 160 milliseconds to network and connection work, 70 to gateway processing, 170 to destination response, and 120 to the minimum rendering work needed for the intended milestone. The total budget is 520 milliseconds, leaving 80 milliseconds of headroom against a 600-millisecond objective. These are engineering allocations, not measured guarantees or a claim that every device and geography can meet them.

Do not add component 95th percentiles and call the sum an end-to-end 95th percentile. Component delays can be correlated, and percentiles do not generally add. Measure complete request traces for the actual objective. If four component budgets each hold with at least 99% probability for the same request population, a union bound gives at least 96% probability that all four hold, without requiring independence. That bound is useful but still depends on valid component measurements.

Keep measurement delivery outside the navigation dependency chain

A customer should not wait for an external measurement endpoint before receiving the destination page. Commit the business action and its eligible delivery intent durably, then dispatch asynchronously. The response can acknowledge the legitimate action once its required internal state is safely recorded. A best-effort background task that vanishes after the response is not a substitute for a durable delivery record.

The proposed NoLimit Shopping Proprietary ACID Engine should atomically commit related internal business state and an outbox entry. That prevents a purchase from being recorded without its intended event, or an event from being emitted for a business transaction that never committed. The NoLimit Shopping Proprietary Ledger should retain the event reference, state transitions, and correction history. These are implementation requirements that must be demonstrated before being advertised as live capabilities.

External delivery remains a separate transaction boundary. A network timeout can occur after the destination received the event but before the sender received the response. Treat that outcome as uncertain and retry the same occurrence according to the supported interface rules. Internal atomicity cannot create universal exactly-once delivery across independent systems. The realistic goal is durable delivery with idempotent handling and explicit reconciliation of unresolved outcomes.

Size the queue from traffic and recovery requirements

Advertising spend alone does not determine event throughput. Consider a hypothetical $20,000 daily campaign portfolio with a $20 CPM and a 2% click-through rate. It buys one million impressions and approximately twenty thousand clicks. If each eligible visit produces six measurement events on average, that is one hundred twenty thousand events daily, or about 1.39 events per second on average. A tenfold peak produces roughly 13.9 events per second.

Now model a fifteen-minute destination outage during that peak. At fourteen incoming events per second, the queue accumulates approximately twelve thousand six hundred events. If the recovered dispatcher can sustain forty events per second while new events continue arriving at fourteen, net drain capacity is twenty-six events per second. The backlog drains in about 484.6 seconds, or 8.08 minutes, assuming the measured capacity remains available and no other bottleneck intervenes.

A dispatcher that only matches the peak arrival rate never clears that backlog while the peak continues. Reserve recovery capacity and respect external rate limits. Bound retries, add jitter to avoid synchronized retry bursts, and maintain a terminal exception path for invalid payloads. Repeatedly resending a permanently invalid record consumes capacity that should serve valid events and makes the oldest unresolved age look worse without improving correctness.

Distinguish retries, duplicates, and conflicting business facts

A retry repeats delivery of the same intended occurrence. A duplicate is an additional representation that should not create another business outcome. A conflict occurs when two records claim the same occurrence but disagree about material facts such as value, currency, or event name. Those situations need different handling. Silently accepting whichever payload arrives last can conceal application defects and corrupt a financial or marketing report.

Preserve the original authoritative payload and a digest or version reference. If a subsequent record has the same identity and the same relevant content, treat it as another delivery attempt. If it conflicts, hold it for an explicit correction workflow. A refund or order adjustment should use the destination's supported event semantics and the merchant's accounting policy; it should not silently mutate a past purchase into a different event merely to force a dashboard total to match.

Define retry eligibility by error class. Transient availability failures may justify retry under the current API contract. Invalid authentication, malformed payloads, or a revoked destination require diagnosis. Stop dispatch when authorization has been removed. Record attempt count, last response category, next eligible retry time, and terminal reason without storing secrets in the audit trail. The operator should be able to explain why a record remains unresolved.

Deduplication failures distort acquisition economics

Assume an advertiser spends $20,000 and generates four hundred real purchases. The actual cost per purchase is $50. If each purchase produces a browser event and a server event and the two paths are not deduplicated, an internal report that blindly sums them could show eight hundred purchases and an apparent $25 cost per purchase. The business has not doubled its sales; the measurement system has doubled its records.

A subtler failure occurs when only some events are duplicated. If one hundred of those purchases are double-counted, the report shows five hundred conversions and a $40 acquisition cost. That is a 20% understatement of the true $50 cost. A director may then increase budgets based on a margin that does not exist. Compare unique business outcomes with delivered event identities before interpreting a sudden improvement as optimization success.

Attribution introduces another distinction. Even a perfectly deduplicated event stream does not guarantee that the platform's attributed conversion count will equal the merchant's total orders. Attribution windows, event eligibility, reporting time, and modeled reporting can differ. Reconcile the event pipeline first, then analyze attribution under documented definitions. Do not corrupt the source event stream to manufacture equality between reports that intentionally measure different things.

Enforce data minimization and permission at dispatch

A server-side transport does not remove the need to respect the user's choices and the business's applicable data-handling obligations. Define which purposes and fields are permitted for each destination, and evaluate that policy before dispatch. Keep necessary evidence of the decision without turning the event log into an unrestricted copy of customer information. The appropriate legal basis and regional requirements need review by the responsible business; the gateway cannot infer them from a successful HTTP response.

For sweepstakes and lead generation, avoid transmitting sensitive answers, identity documents, or unrestricted free text as generic event properties. A lead's existence and authorized measurement attributes are different from the full contents of a form. If a user's permission changes before a queued event is sent, apply the reviewed dispatch policy rather than blindly replaying every historical record. Retention and deletion rules should cover queues and diagnostic exports as well as the main business system.

Hashing an identifier is not a universal declaration that the data is anonymous or permitted to share. Use only the transformations and fields required by the current destination contract and the approved business purpose. Keep credentials on the authorized server side and rotate them under controlled procedures. A proposed NoLimit Pro Tools Suite validator should operate on fictional or redacted payloads and should never request production access tokens.

Treat destination integrity as a release requirement

Version the advertised offer, landing page, consent interface, and measurement configuration together. A new page release can change form completion behavior even when the event adapter is untouched. A new redirect can strip a legitimate campaign parameter or introduce an open-redirect defect. Use an approved destination map and reject arbitrary user-supplied redirect targets. Routing should be based on genuine product and localization requirements, not an attempt to classify reviewers.

Test the same substantive offer on supported devices, languages, and consent states. Confirm that eligibility terms, pricing, sponsor identity, and any material conditions remain available. Where a market is not eligible, provide a truthful unavailable-market response rather than concealing a different offer behind the same advertisement. Legal review of a promotion and technical review of its measurement are separate acceptance gates; passing one does not establish the other.

A release record should state who approved the offer, which payload contract was tested, and how rollback works. Preserve the previous approved configuration so that an internal defect can be reversed without inventing events or losing the event queue. Do not roll back a security correction merely to restore a better-looking conversion rate. The incident owner needs an explicit rule for balancing measurement continuity against a discovered privacy or authorization problem.

Define service objectives with separate error budgets

Suppose the gateway receives two million valid requests in a month and the internal availability objective is 99.9%. A request-based error budget permits two thousand unsuccessful requests under that definition. It does not mean the service may be unavailable for a particular number of minutes, because traffic is uneven. Define which failures count, which requests are valid, and whether a misleading successful response is considered a failure of correctness.

Maintain a separate event-freshness objective, such as the proportion of eligible committed events reaching a resolved delivery state within an internally chosen interval. Do not claim that interval is a platform guarantee. Track queue depth, oldest eligible event age, invalid-payload rate, conflict rate, and destination-specific acceptance. A fast gateway with an aging event backlog has met one objective and failed another; averaging the two into a single green dashboard hides the problem.

Alerts should identify the owner and the next diagnostic step. Rising navigation latency belongs to the destination or routing team; invalid event fields belong to the release owner; expired credentials belong to the access owner. Include a tenant breakdown so that one noisy client's issue does not obscure another client's missing data. Protect diagnostic access with the same tenant boundaries as the business records themselves.

Publish proof that matches the claim

A defensible technical case study includes the workload, date range, sampled geographies, device mix, latency milestone, percentile, and number of observed requests. If the claim is a sub-600-millisecond gateway response, publish the gateway measurement rather than substitute a local developer-machine result. If the claim concerns navigation, include realistic end-user measurements and disclose the coverage. Do not publish an average as though it were a tail-latency commitment.

For NoLimit Shopping, ask the Admin Desk at @markzuckerads for the current scope of any offered integration and its supporting evidence. A proposed Serverless Edge Gateway should be evaluated on offer consistency, durable event delivery, authorization, and measured performance. The publication standard is a complete chain from legitimate customer action to traceable reporting, with limitations visible wherever the evidence stops.

Rehearse the failures that threaten correctness

Before launch, replay a small fictional dataset containing an ordinary purchase, a repeated browser notification, a repeated server notification, a delayed response, and a conflicting value for an existing occurrence. The expected result should be written before the test: one authoritative business occurrence, traceable delivery attempts, and an explicit exception for the conflict. A successful HTTP response is not the only acceptance criterion. Inspect the ledger and the downstream test diagnostics together.

Also simulate a tenant-routing mistake and a revoked dispatch permission. Both should fail closed without exposing another client's data or sending an unauthorized event. Test a gateway response when the external measurement endpoint is unavailable; the legitimate customer journey should follow its defined behavior while durable eligible events remain recoverable. Measure recovery under the expected arrival load, not only when the test queue is empty. These exercises substantiate the architecture's actual boundaries and reveal whether its performance target was achieved by sacrificing evidence or durability.

Sources and evidence scope

• [S1: Google Ads — Circumventing systems](https://support.google.com/adspolicy/answer/15938075?hl=en). Official distinction between deceptive cloaking and legitimate destination variation; reviewed September 23, 2026.
• [S2: Meta for Developers — Handling duplicate browser and server events](https://developers.facebook.com/documentation/ads-commerce/conversions-api/deduplicate-pixel-and-server-events). Public indexed developer summary; full page retrieval was unavailable during research.
• [S3: Meta for Developers — Server event parameters](https://developers.facebook.com/documentation/ads-commerce/conversions-api/parameters/server-event). Public indexed description of event identity fields. Verify the current API contract before implementation.