Propose a scalable entitlement architecture for complex rules

What's really being asked

The interviewer wants to see if you can separate a user-facing hot path that must stay fast from a background policy layer that tolerates slightly stale data. They are looking for mastery of caching hierarchies, async event-driven architectures, and horizontal scaling rather than simply upgrading a database.

The full answer

First, an edge-cached token strategy where the entitlement service issues signed JWTs or capability tokens encoding the current plan, features, and add-ons, letting API gateways validate access locally in under five milliseconds without hitting the core service. Second, an async quota pipeline that ingests usage events into a stream and updates counters in a separate store, so the hot path only reads a cached limit rather than writing to a shared row on every request. Third, a rules microservice that evaluates complex business logic such as geographic restrictions or promotional bundles offline and publishes updated token schemas to the edge cache. Fourth, horizontal scaling of the token issuer and rules engine behind load balancers with no session affinity, plus regional deployment to keep latency under fifty milliseconds globally.

The mistakes people make

Proposing to shard a single relational database and still query it synchronously on every request. Suggesting a distributed two-phase commit across the entitlement service and a billing database to enforce quotas in real time. Recommending a monolithic rules engine that evaluates all add-ons and quotas inline inside the request thread. Ignoring cache invalidation entirely or assuming a five-second TTL is acceptable for premium features without a push-based refresh mechanism.

What usually comes next

How do you handle cache invalidation when a user upgrades mid-session? What happens if the async quota pipeline lags and a user briefly exceeds their limit? How would you model entitlements for a B2B tenant with thousands of seats and custom add-ons? Walk me through the fallback path if the edge cache is unreachable.

A concrete example

A video streaming platform checks entitlements on every play button click. Instead of querying a subscription database, the API gateway verifies a signed edge token that lists the plan tier and available codecs. Usage minutes are streamed to Kafka; a consumer updates a Redis counter every few seconds. When the user buys a 4K add-on, the rules microservice revokes the old token and pushes a new one to the edge POPs within two hundred milliseconds, keeping the play path fast while still enforcing complex upsell logic.