Scalable REST API Design

What they ask

The technical round is run by a senior engineer and mixes three things: a design discussion, a bit of live coding and a scenario or two. The design part is the one people remember. After a few minutes on your stack (the recruiter screen already asked about JavaScript, React and Node.js), you are asked to design a REST API for a service that has to keep working as traffic grows. Typical framing: an orders endpoint for a retail client, or a notifications service used by several apps.

You are expected to talk through resources and routes, request and response shapes, pagination, authentication, rate limiting, caching, how the service scales horizontally, what the database looks like and how you keep a POST idempotent when a client retries.

The scenario part is usually a short Node snippet with a bug (a promise that is never awaited, an off-by-one in pagination, an unhandled rejection) that you debug out loud.

What they look for

• A clean resource model before any talk of scaling.
• Tradeoffs stated explicitly: offset vs cursor pagination, cache invalidation cost, when a queue is worth it.
• Failure modes: what happens when the DB is slow, when a downstream call times out, when the same request arrives twice.
• Calm, readable debugging rather than guessing.