Most engineers design APIs like this: “Just add a GET and a POST.” Then production hits and the API becomes impossible to evolve, secure, or debug. See this real API design problem statement that exposes weak thinking: Problem: Design the API for a multi-tenant SaaS product where customers can create projects, invite team members, and track usage. Requirements: • Customers must not see each other’s data • You need to support both web and mobile clients • Usage data can be large and must be paginated • The API will be used by third-party integrations later • You must support adding new features without breaking existing clients Most candidates immediately start listing endpoints. Top engineers start with these questions: 1. How do you isolate tenants? • Path: /tenants/{id}/projects • Header: X-Tenant-ID • Subdomain • What happens if a client sends the wrong tenant ID? 2. How do you version the API? • /v1/projects • Header versioning • What is your plan when you need to remove a field? 3. How do you paginate large lists? • Offset-based (simple but breaks when data changes) • Cursor-based (stable but harder for clients) • Which one do you choose and why? 4. How do you handle authentication and authorization? • Token proves identity • Every request still needs a permission check • Can a user from Tenant A access a project in Tenant B by guessing the ID? 5. How do you design for third-party use? • Rate limits per client • Clear error codes • Idempotency for write operations • What happens when a client retries a failed request? 6. What is your error contract? • Do clients get 400 with a machine-readable code or a vague 500? • How do you avoid leaking internal details? The real problem is not “what endpoints do I need.” It is “how does this API stay safe, stable, and usable when the product and the number of clients grow.” If you cannot answer the tenant isolation and pagination questions clearly, the rest of the design does not matter. How would you handle tenant isolation in this API - path, header, or something else?

Being an IIT alumni doesn't guarantee job security

Most backend engineers learn in fragments A tutorial here, A Stack Overflow answer there. I spent 10 weeks building the complete picture. APIs → Caching → Queues → Load Balancing → Microservices → DB Scaling → API Gateway → Monitoring → Security → CI/CD 10 weeks, 10 articles, One foundation. Full series + all Medium articles in first reply 👇