Third-Party and SaaS Integration Questions

Approach (brief)
Use suspend-friendly delays with jitter, exponential backoff capped by maxDelayMs, respect cancellation via coroutines, and return true on success or false after attempts.

Kotlin implementation

import kotlinx.coroutines.delay
import kotlin.math.min
import kotlin.random.Random
import kotlinx.coroutines.isActive
import kotlinx.coroutines.CancellationException
import kotlinx.coroutines.coroutineScope

suspend fun retryWithExponentialBackoff(
    initialDelayMs: Long,
    maxDelayMs: Long,
    maxAttempts: Int,
    jitterFactor: Double = 0.5, // fraction of calculated delay used for jitter
    block: suspend () -> Boolean
): Boolean = coroutineScope {
    require(initialDelayMs > 0 && maxDelayMs >= initialDelayMs && maxAttempts > 0)
    var attempt = 0
    var delayMs = initialDelayMs
    while (attempt < maxAttempts && isActive) {
        attempt++
        if (block()) return@coroutineScope true
        if (attempt >= maxAttempts) break
        // apply jitter: random between delay * (1 - jitterFactor) and delay * (1 + jitterFactor)
        val jittered = (delayMs * (1.0 - jitterFactor) + Random.nextDouble() * (delayMs * 2 * jitterFactor)).toLong()
        val wait = min(jittered, maxDelayMs)
        delay(wait) // cancellable, non-blocking
        delayMs = min(delayMs * 2, maxDelayMs)
    }
    false
}

Why this works / notes

• Uses coroutineScope + isActive so cancellation propagates and delays are cancellable.
• Jitter reduces thundering herd by randomizing waits.
• Non-blocking: uses suspend delay, safe on main/UI coroutine if launched with proper dispatcher.
• Edge cases: validate params, tune jitterFactor (0..1), consider adding retryable error detection instead of simple Boolean.

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.

Decision factors
I would compare three options against four needs: speed to launch, complexity, maintainability, and latency. A native connector is simplest when the CRM and marketing tool already support the fields and schedule you need. An integration platform is good when you want faster setup, monitoring, and moderate customization. A custom API integration fits when rules are unique, scale is high, or data freshness matters.

Example
If the team only needs a nightly sync of name, email, and campaign status, a native connector is usually enough. If they later need updates within 5 minutes when a lead converts, I would move toward an API-based or event-driven design, because batch sync may be too slow.

My rule
Start with the least complex option that still meets the business need. If near-real-time updates become required, I would favor a design with webhooks or APIs plus retries and monitoring, because it gives better control over freshness and failure handling than a purely batch connector.

I would design this as a policy-driven event pipeline so the rules are enforced once, not reimplemented in each destination.

Flow
Website event -> ingestion API -> consent and policy service -> transform/mask layer -> routing to analytics, CRM, and ad platforms.

Key ideas

• Consent means the user has allowed a specific use, such as marketing.
• Masking means replacing sensitive values with partial or tokenized data.
• Retention means deleting or expiring data after a defined time.
• Access rules mean only approved services and roles can read certain fields.

How it works
Each event carries a user ID, region, consent flags, and a policy version. The policy service decides what can be stored and where it can go. Analytics may receive pseudonymous events, CRM may receive only contact data for opted-in users, and ad platforms get nothing unless marketing consent is true. Regional rules are checked before export, so a field allowed in one country can still be blocked in another.

Worked example
If a user in France submits email, city, and campaign click data, but has not accepted marketing, the system can keep the click for product analytics, mask the email for internal logs, skip CRM and ads, and schedule deletion after the retention period.

Trade-offs
Centralized policy adds some latency and complexity, but it is the right choice because it prevents inconsistent handling across destinations and makes audits much easier.

Overview of methods (concise)

• GET — Read resource. Safe (doesn't change state) and cacheable. Idempotent by definition.

  • Mobile scenario: Fetch user profile or feed on app launch.
  • Caching: Use HTTP caching (ETag/Cache-Control) to reduce data and save battery.
  • Retries: Safe to retry automatically on network flap; duplicates harmless.

• POST — Create or submit data; not safe, not idempotent by default, usually not cacheable.

  • Mobile scenario: Submit a new comment or create an order.
  • When to prefer: Use POST when server assigns ID or action triggers side-effects (emails, payments).
  • Retries: Client must avoid blind retries — implement deduplication (idempotency-key) or show retry UI.

• PUT — Replace or create resource at known URI; idempotent (repeat yields same state), not safe.

  • Mobile scenario: Upload edited user settings/profile to /users/{id}.
  • When to prefer over POST: Use PUT when client knows resource URI/ID and sends full representation.
  • Retries: Safe to retry in background (idempotent), good for unreliable mobile networks.

• PATCH — Partial update; not necessarily idempotent but often designed to be idempotent if server implements it that way.

  • Mobile scenario: Toggle a single preference or update one field in profile.
  • Retries: Prefer idempotent PATCH semantics or include versioning (optimistic locking) to avoid conflicts.

• DELETE — Remove resource; idempotent (deleting multiple times same result), not safe.

  • Mobile scenario: Delete a photo or bookmarked item.
  • Retries: Safe to retry; handle 404 as success.

Mobile-specific considerations

• Prefer PUT for full-resource syncs (background syncs, retries allowed). Prefer POST for create/operations with side-effects or server-generated IDs.
• Use idempotency keys for POSTs when network flaps may cause duplicates.
• Backoff and retry: automatic safe retries for GET/PUT/DELETE; for POST/PATCH, implement client-side dedupe and user-visible retry/failure handling.
• Caching and battery: leverage Cache-Control/ETag; prefer conditional requests (If-None-Match) to save bytes and power.