Support impersonation with audit
Design a secure 'log in as customer' / support-impersonation system: support engineers must sometimes act inside a customer's account to debug, but this is a huge trust and compliance surface. Requirements: impersonation requires customer consent or an approved ticket; the impersonating session is clearly distinguishable from the real user (so writes are attributable to the staff member, not the customer); some actions (export PII, change billing, delete data) are blocked even during impersonation; and every action is immutably audited. Scale: thousands of support staff, millions of customers. Discuss the token/identity model, scope restriction, consent, and audit.
Clarify scale and constraints first. Propose a clean component breakdown, then go deep on the hard parts (data model, bottlenecks, consistency, failure modes) and name the trade-offs you are making.