Implement middleware for your APIs to handle authentication and authorization. Walk through what you would check before allowing a request.
One question. More depth.
Find a scenario, form an answer, and see where the follow-up takes you.
30 scenarios to explore
Your checkout calls a payment provider. How would you handle a request that times out?
Before creating an order, your API checks that a product is in stock. How would you implement the reservation?
Product pages are slow. You add a cache for product information, including prices.
A queue consumer processes order events and grants loyalty points.
An authenticated user requests an invoice by its ID. Which access checks should the API perform?
A frequently used database query is slow. What would you investigate before adding an index?
Limit each account to 100 API requests per minute.
Create an order in a database and publish an order-created event to a broker.
Design pagination for a feed sorted by newest first.
Your API calls three downstream services before returning a response.
Rename a database column used by an API while keeping the service available.
Your system sends writes to a primary database and reads to replicas.
Design an API for uploading large user files over unreliable connections.
Add request logging to make production API failures easier to investigate.
Build a search box that loads results as the user types.
Design a confirmation dialog for deleting a saved item.
A dashboard becomes unresponsive when it displays thousands of records.
Make a task’s completed checkbox update instantly when clicked.
Change an API response field from a string to a structured object.
Your web app uses a session cookie to authenticate requests that change account settings.
Choose the health checks and alerts for a checkout service.
A new release causes a spike in errors. What is your recovery plan?
Define a backup plan for an important database.
A checkout test fails intermittently in CI but usually passes locally.
Plan testing for a new payment integration.
A release changes login, a reporting filter, and a footer. Testing time is limited.
Engineers say the current service is hard to change and should be rewritten.
A customer commitment has a fixed launch date, but the team’s estimate is twice the available time.
Two experienced engineers disagree on an architectural choice and the team is blocked.