Adobe Entitlements And Transactional Integrity

What's being tested

Interviewers are probing your ability to design and reason about an entitlements system that enforces correct access rights while preserving transactional integrity across billing, catalog, and user-facing services. Expect questions on correctness (no double-grants, no stuck trials), latency/availability tradeoffs, and concrete failure modes in distributed flows. Adobe cares because license/access mistakes directly impact revenue, legal risk, and user trust — demonstrate safe, scalable patterns engineers own.

Core knowledge

Entitlement model: authoritative source-of-truth (account or subscription record) containing SKU, start/end timestamps, state, and reasons; prefer a normalized entitlement row keyed by (user_id, sku_id, grant_id).
ACID vs BASE tradeoff: strong ACID transactions simplify correctness but limit distribution; BASE/eventual consistency scales but requires compensating logic and reconciliation for invariants.
Two-phase commit (2PC) vs Sagas: 2PC gives atomicity across databases but is blocking and brittle; saga (choreography/coordination) uses compensating transactions and is practical for microservices.
Idempotency: require idempotency keys on operations (billing charge, grant call) so retries do not duplicate effects; follow Stripe-style idempotency semantics for at-least-once delivery.
Exactly-once vs at-least-once: design for at-least-once delivery at service boundaries, make operations idempotent; use CDC+dedupe or dedup_id to achieve effectively-once in event sinks.
Optimistic concurrency: use a version or updated_at column plus conditional writes (WHERE version = x) to avoid lost updates; fall back to retries or user-visible conflict resolution for high-contention SKUs.
Compensating transactions: model reversals explicitly (refunds, revocations) and persist compensating reason and idempotency; automate background cleanup for partial failures.
Event sourcing / CDC: use Change Data Capture to emit deterministic events from Postgres/Aurora for downstream consumers (catalog, metrics); make events schema-versioned and idempotent.
Latency and user experience: fast-path should grant provisional access locally (cache Redis) while async reconcile confirms entitlement; clearly define what "provisional" means to UX and billing.
Failure modes & monitoring: instrument reconciliation queues, failed saga steps, and charge/grant mismatches; alert on drift ratios > 0.1% or rising. Track p99 latency and reconciliation backlog.
Data retention & legal: keep audit trail (who granted, why, timestamps) immutable for compliance; use append-only logs or event store for investigation.
Capacity/scale guidance: single Postgres region ok for < ~100k writes/s; beyond that shard by account or SKU and rely on async aggregation for global views.

Worked example

Design an entitlement flow for converting a trial to paid subscription while ensuring no double-charges and consistent access. First 30 seconds: ask what operations are in scope (charge, grant entitlement, notification), SLAs for access (<500ms?), and failure semantics (allow provisional access?). Organize the answer around three pillars: authoritative billing transaction, atomicity strategy between billing and grant, and reconciliation/audit. Propose charging first with an idempotency key; on successful charge, publish an immutable event (charge_succeeded) to a durable queue (Kafka) consumed by entitlement service which performs a conditional insert (WHERE version = x) to create the paid entitlement. Flag an explicit tradeoff: charging-first risks taking money before granting access on rare failure — mitigate with compensating refund automatic retries and user-facing provisional access token. Close by noting you'd instrument end-to-end traces, add a reconciliation job to surface mismatches, and, if given more time, design a schema migration plan and test harness for chaos/network partitions.

A second angle

Now consider bulk license assignment for enterprise customers where you must provision thousands of seats atomically. The same concepts apply but constraints shift: blocking 2PC across many downstream systems becomes impractical. Use a coordinated saga with a central coordinator that issues per-seat grant commands and tracks outcomes, offering transactional semantics at the batch level (all-or-none or best-effort with rollbacks). Emphasize backpressure and rate-limiting to downstream provisioning systems, and design batch checkpoints so partial progress can be resumed without reprocessing already-successful grants. For billing, prefer a single aggregated invoice event to reduce charge duplication risk and use idempotency keys per-batch plus per-seat dedupe IDs.

Common pitfalls

Pitfall: Assuming synchronous atomicity across billing and entitlement services without considering network partitions. This leads to either lost charges or unauthorized access; instead, choose an explicit consistency model and document client-visible semantics.

Pitfall: Relying solely on in-memory caches for entitlement checks without versioning or TTLs. Cache staleness causes access errors; always back cache with a canonical store and incorporate short TTLs plus on-miss validation.

Pitfall: Treating retries as free. Blind retries of grant or charge operations create duplicate side effects; require idempotency keys, persistent dedupe records, and careful retry backoff with jitter.

Connections

Interviewers may pivot to adjacent areas like billing systems (invoice/coupon handling, chargeback), rate-limiting/quotas (throttle entitlements), or security (token-based access for entitlements, oauth scopes). They might also ask about data consistency patterns in high-throughput services or how to test chaos scenarios.