Third-Party and SaaS Integration Questions

Approach
I would resolve identities with a layered matching strategy. Identity resolution means deciding which records refer to the same person. I would use deterministic rules first, then probabilistic rules when the evidence is weaker.

Trust and merge rules

• Treat login-linked identifiers such as verified email or account ID as high trust.
• Treat anonymous cookies as temporary and link them only after a login or strong correlation.
• Prefer source systems that own the data, for example the billing system for account status.
• Keep conflicting attributes as separate fields with lineage when the source is uncertain.

Example
A browser cookie c123 later logs in as jane@example.com and maps to account A77. I would merge those into one person profile because the login creates a strong bridge. If another record also uses jane@example.com but has a different customer since 2021, I would not auto-merge until I verify whether it is a shared inbox or a duplicate account.

Decision rule
Merge when confidence is high and the identifiers form a clear chain. Keep separate when the match could create a false positive, because over-merging is harder to undo than under-merging.

Clarify goals & constraints
I’d prioritize protecting transaction availability and PCI/PCI-DSS compliance while keeping costs predictable. Assume SLA expectations: 99.95% regional uptime, 30s max auth latency, and defined reconciliation windows.

Contract clauses

• SLA with financial remedies: tiered service credits and revenue-based penalties for missed availability/latency targets.
• Termination & remediation: right to terminate after N consecutive breaches or X% annual downtime; mandatory remediation plan with timelines.
• Data & security: explicit PCI scope, breach notification within 24 hours, forensic access, and joint incident response.
• Change control & roadmap: 90‑day notification for API/version changes; freeze periods during peak sales.
• Audit & compliance: right to quarterly third‑party audit reports and on‑site reviews annually.

Monitoring & KPIs

• Active synthetic checks (per region) every 15s for auth/pay endpoints.
• Real-time metrics: success rate, latency P50/P95/P99, error codes, queue depth.
• Alerting + automated runbooks; expose provider metrics via shared dashboard and monthly SLA reports.

Risk-sharing

• Cap on provider liability tied to direct losses; escrow of critical components/keys; joint war‑room for incidents.
• Financial split on chargeback/fraud arising from provider faults.

Fallback architecture

• Multi-provider payment routing with circuit breaker & dynamic routing (failover on error rate/latency threshold).
• Local async queue + retry/backoff; fallback to tokenization/local vault for stored-credentials to complete payouts later.
• Graceful UX: offer “pay later” or alternate provider choice when degraded.
• Playbooks for reconciliation and idempotency to avoid duplicate charges.

Implementation & metrics

• Rollout phased: pilot in non-peak region, then global. Measure MTTR, failed payments reduction, and cost delta vs risk mitigated.

Recommendation
For unsubscribes, I would centralize the consent workflow and let other systems react to the resulting event. This is a case where correctness matters more than loose independence, because one missed suppression can create a compliance problem.

How I would decide

• Centralize if there is one business rule for consent, one audit trail, and a hard deadline before the next send.
• Use choreography only when systems are loosely coupled and temporary delay is acceptable.

Failure modes I would watch

• A service misses the unsubscribe event
• A retry causes duplicate updates
• A campaign send races ahead of the suppression update
• One system updates from stale cache while another is current

Example
If a user opts out at 9:10 and a campaign is scheduled for 9:15, the central consent service should record the change immediately, publish an event, and block sends until all critical destinations confirm receipt or until the campaign filter reads from the central source of truth.

Control plane
I would add retries, dead-letter handling, a reconciliation job, and a pre-send suppression check so the system stays safe even if one downstream service is slow.

Signals to check
I would look at three layers: producer, pipeline, and vendor. Producer signals include send rate, retry rate, and publish latency. Pipeline signals include queue depth, age of oldest message, consumer lag, and dead-letter growth. Vendor signals include 429 responses, timeout rate, and response latency.

How I would interpret it
If the queue grows while the producer rate is flat and vendor 429s rise, the bottleneck is likely the vendor. If queue depth rises but the vendor looks healthy, the consumer or transformation layer may be slow. If the producer rate spikes unexpectedly, the issue may be upstream demand.

Controls

• Apply backpressure, so producers slow down when the queue age crosses a threshold
• Use rate limits and bounded concurrency per destination
• Prioritize fresh or user-facing updates over low-value backlog
• Pause or batch noncritical sends when the vendor is throttling
• Use retries with jitter and a dead-letter queue for repeated failures

Example
If oldest-message age jumps from 2 minutes to 18 minutes and the vendor starts returning many 429s, I would cap concurrency, lower request rate, and alert on freshness rather than just queue size, because old messages are often more harmful than a larger queue.

Approach
I would make the consumer idempotent. Idempotent means the same event can be processed twice without creating two results. The core pattern is: persist the raw webhook first, dedupe by a stable event key, then process asynchronously.

Design

• Require an event_id from the sender, or derive a fingerprint from source system, object id, and version.
• Store each event in an inbox table with a unique constraint on that key.
• Ack the webhook only after the raw event is durably stored.
• Use upserts in downstream tools keyed by the business entity, such as lead_email or external_lead_id.
• Track event version or updated_at so older events do not overwrite newer state.

Example
If lead 123 arrives twice at 10:01 with the same event_id, the first insert succeeds and the second is ignored by the unique constraint. If a newer update at 10:03 changes the phone number, the processor applies that one because its version is later.

Failure handling
I would add retries with backoff, a dead-letter queue for poison messages, and periodic reconciliation so partial failures do not silently drift.