OAuth
OAuth is an authorization framework. It lets a client access protected resources with tokens instead of asking the user to share credentials with every application.
Authentication answers "who are you?" Authorization answers "what can you access?" OAuth mainly solves delegated authorization.
Idempotency
An operation is idempotent if repeating it produces the same final result as doing it once. This matters in distributed systems because clients may retry after timeouts.
Example: retrying a payment request should not charge twice. An idempotency key can let the server recognize and return the original result.
Distributed Transactions
A distributed transaction spans multiple services or databases. Strong distributed transactions can become slow, fragile, and hard to scale. Microservice systems often use sagas, compensating actions, outbox patterns, and eventual consistency instead.
Interview Scenario Practice
Scenario 1: Payment API Retried Twice
Scenario: A payment request times out and the client retries. You must avoid charging twice.
Strong answer: Use an idempotency key. Store the key with the first result and return the same result for duplicate retries.
Why it works: Retries are normal in distributed systems, so APIs must protect side-effecting operations from duplicate execution.
Common mistake: Assuming a timeout means the server definitely did not process the request.
Scenario 2: Login With Third-Party Access
Scenario: A user wants your app to access their calendar without sharing their calendar password.
Strong answer: OAuth enables delegated authorization using tokens. The user grants limited access through the provider.
Why it works: The client receives an access token with defined scope instead of storing the user's password.
Common mistake: Describing OAuth as only authentication. OAuth is mainly authorization; identity often comes through OpenID Connect.
Scenario 3: Distributed Transaction Fails Halfway
Scenario: Order creation succeeds, but payment capture fails.
Strong answer: Use a saga-style flow with explicit states and compensating actions, such as marking the order payment-failed or releasing reserved inventory.
Why it works: Long-running distributed workflows need recovery steps instead of pretending every service can share one local transaction.
Common mistake: Forcing a global distributed transaction everywhere, hurting availability and scalability.
Discussion
0 comments
Ask a question or share what stood out to you.