The technology choices behind Netflix, Uber, WhatsApp, Instagram, Spotify and Airbnb reveal something the framework debates on social media rarely admit: there is no universally “best” stack. There is only the right stack for a specific problem, at a specific scale, with a specific team. Here is what each of these companies actually runs on — and the lesson behind each choice.

Netflix: Java, Cassandra and a Custom-Built CDN

Netflix serves over 300 million subscribers across 190 countries and is responsible for a significant share of global downstream internet traffic. Its technology choices reflect the scale of that challenge.

The frontend runs on React, with GraphQL (via Netflix’s open-source DGS framework) handling data fetching for most modern client surfaces, after years of relying on a custom system called Falcor. The backend is built predominantly in Java with Spring Boot, powering thousands of independently deployable microservices. Python and Go handle specific domains including machine learning and observability tooling.

For data storage, Netflix relies on Apache Cassandra as its primary scale-out NoSQL store, EVCache (a memcached-based system) for high-speed caching, and MySQL for transactional data like billing. Real-time data movement runs through Kafka and Netflix’s own streaming platforms, Mantis and Keystone.

Perhaps the most striking architectural decision is Open Connect — Netflix’s proprietary content delivery network. Rather than relying entirely on third-party CDNs, Netflix places its own caching servers directly inside internet service provider networks around the world, pushing content as close to viewers as possible during off-peak hours.

The lesson: when you operate at a scale where standard infrastructure no longer fits your problem, building proprietary infrastructure becomes the rational choice — not over-engineering.

Uber: Polyglot Microservices Built for Real-Time Geography

Uber’s engineering challenge is fundamentally about real-time coordination across location, time and millions of simultaneous transactions. The company’s technology stack reflects a deliberate move away from a single dominant language toward a polyglot microservices architecture.

Uber’s backend spans Go, Java and Node.js, chosen for different services based on performance requirements and team expertise. The company famously built its own database system, internally known as Schemaless, on top of MySQL to handle the specific consistency and scale requirements of ride data. PostgreSQL and MySQL both appear throughout the broader system for different workloads. Kafka handles the real-time event streaming that powers live trip tracking, surge pricing calculations and driver-rider matching.

Uber migrated from an early monolithic architecture to microservices specifically because a single application could not be scaled, deployed and maintained fast enough to support the company’s growth. This migration was not undertaken on day one — it happened in response to genuine scaling pressure.

The lesson: architecture should follow the shape of your actual problem. Uber’s real-time, geographically distributed coordination problem demanded an architecture that could evolve service by service, rather than a single codebase trying to do everything.

WhatsApp: Erlang and the Power of the “Boring” Choice

WhatsApp’s technology story is one of the most instructive in the industry. At the time of its acquisition by Facebook in 2014, WhatsApp was famously serving hundreds of millions of users with an engineering team that numbered only in the dozens.

The reason this was possible comes down largely to one technology choice: Erlang. Erlang is a programming language originally built by Ericsson for telecommunications systems — designed from the ground up to handle massive numbers of concurrent, lightweight connections with extremely high reliability. It is not a trendy language. It was never going to top a “hottest frameworks of the year” list. But it was exactly suited to WhatsApp’s core problem: keeping millions of persistent connections open simultaneously, reliably, with minimal overhead.

The lesson: the most-discussed technology is rarely the most appropriate one. WhatsApp chose a niche, decades-old language because it was the correct tool for the specific problem — and that choice let a tiny team support an enormous user base.

Instagram: Scaling to a Billion Users on Python

Instagram is frequently cited as proof that the programming language you choose matters far less than how you architect around it. The platform’s backend is built primarily in Python using the Django framework — a combination often dismissed as too slow for applications at serious scale.

Instagram has scaled past a billion users on this foundation. The data layer relies on PostgreSQL for core relational data and Cassandra for specific high-volume, high-availability workloads. Caching is handled through Memcached and Redis, which absorb the read load that would otherwise hit the database directly for every request.

What made this scale possible was not a language switch but disciplined engineering around the language: aggressive caching strategies, careful database sharding, asynchronous processing for non-critical paths, and a willingness to optimise the specific bottlenecks that actually appeared under real load rather than guessing in advance.

The lesson: a programming language’s raw performance characteristics matter far less at scale than the architecture built around it. Bad architecture will make a fast language slow. Good architecture can make a famously “slow” language scale to a billion users.

Spotify: Microservices and the Squad Model

Spotify’s technology stack centres on Java and Python across a large number of independently owned microservices, with Google Cloud Platform and BigQuery handling much of its data infrastructure, and Kafka powering real-time event streaming for everything from play counts to recommendation signals.

What makes Spotify particularly interesting is not just the technology but the organisational model built around it. Spotify popularised the “squad” model — small, autonomous, cross-functional teams that each own a specific service or feature area end to end, with the freedom to choose their own tools and deployment cadence within broad guardrails.

This organisational structure and the underlying microservices architecture reinforce each other. Independent services map naturally onto independent teams, allowing Spotify to ship changes across a vast product surface without every team needing to coordinate on every release.

The lesson: technical architecture and organisational structure are deeply connected. The way you split your codebase into services often ends up mirroring — or should mirror — the way you split your teams. This is sometimes called Conway’s Law, and Spotify is one of its most-cited modern examples.

Airbnb: Starting on Rails, Evolving Under Scale

Airbnb’s technology story is a useful counterpoint to the others on this list because it illustrates evolution rather than a single static stack. The platform was originally built on Ruby on Rails — a framework chosen specifically for the speed at which it allowed a small founding team to build, iterate and ship a working product.

As Airbnb scaled into a global marketplace processing complex search, pricing and trust-and-safety logic, the company began migrating performance-critical and team-isolated portions of its system toward service-oriented architectures using languages including Java and Kotlin, while React became the standard for frontend development. MySQL and Redis remain core to the data layer.

Airbnb did not rewrite everything overnight, and it did not start with a microservices architecture from day one. The migration happened gradually, driven by specific scaling pain points rather than a wholesale rejection of the original technology choice.

The lesson: starting with a framework optimised for development speed is often the correct early-stage decision, even if it is not the architecture you will run at massive scale. Re-architecting in response to real growth is normal and expected — it is not a sign that the original choice was wrong.

What These Six Stacks Teach Every Founder and CTO

Looking across all six companies, four patterns emerge that matter far more than any individual technology choice.

There is no universally best stack. Java works for Netflix and Spotify. Python works for Instagram. Erlang works for WhatsApp. Ruby on Rails worked for early Airbnb. Each choice was correct for the problem, team and stage it was made for — not because of any inherent superiority of the language itself.

Boring, proven technology beats trendy technology at scale. None of these companies built their core infrastructure on whatever was generating the most hype on social media at the time. Cassandra, MySQL, Kafka and PostgreSQL are not exciting choices. They are reliable ones, with deep operational knowledge available across the industry.

Architecture matters more than the language itself. Instagram on Python and WhatsApp on Erlang both scaled to enormous user bases despite using technologies that are, by raw benchmark numbers, far from the fastest options available. The architecture built around the language — caching strategy, database design, service boundaries — determined the outcome far more than the language choice alone.

Start simple and re-architect when growth demands it. Airbnb did not start with a complex microservices architecture. WhatsApp did not start by trying to anticipate Facebook-scale traffic. Every one of these companies built something that worked for their actual stage, then evolved the architecture as real scaling pressure emerged — not in anticipation of hypothetical future scale.

How Onclick Innovations Approaches Technology Decisions

At Onclick Innovations, we do not have a default stack we push onto every client regardless of fit. We have built production applications in React, Vue and Angular for the frontend, and Node.js, Python, PHP and Java for the backend — choosing based on the specific project, team, timeline and long-term maintenance considerations involved.

The pattern across the six companies in this article holds true for every project we work on, regardless of size: the right technology choice is the one that fits the actual problem you are solving today, with room to evolve as your product and user base grow. Not the most fashionable choice. Not the one with the most active hype on social media this month. The right one for your specific situation.

If you are making technology decisions for a new product, or reconsidering the architecture behind an existing one, we are happy to talk through the tradeoffs honestly.

📩 Get in touch → www.onclickinnovations.com
📍 Based in Mohali, India · Serving clients globally across 10+ countries

Frequently Asked Questions

What programming language does Netflix use?

Netflix uses Java with Spring Boot as the primary language for its backend microservices, React for its frontend, and Python and Go for specific domains like machine learning and observability. Its data layer relies on Apache Cassandra, EVCache and MySQL, with Kafka handling real-time event streaming.

Why does WhatsApp use Erlang?

WhatsApp chose Erlang because it was specifically designed for telecommunications systems that need to handle massive numbers of concurrent, lightweight connections with high reliability and minimal overhead. This made it exceptionally well suited to WhatsApp’s core technical challenge of maintaining millions of simultaneous persistent connections, allowing a small engineering team to support an enormous global user base.

How did Instagram scale to a billion users on Python?

Instagram scaled on Python and Django through disciplined architecture rather than raw language performance: aggressive caching with Memcached and Redis, careful database sharding across PostgreSQL and Cassandra, and asynchronous processing for non-critical operations. This demonstrates that architectural decisions around a language matter more than the language’s raw benchmark speed.

Should a startup choose the same tech stack as a company like Netflix or Uber?

No. The technology choices made by Netflix, Uber and similar companies were shaped by their specific scale, team size and problem domain at the time those decisions were made — often after years of evolution from much simpler starting points. A startup should choose technology that fits its current stage, team expertise and actual requirements, with an architecture that can evolve as real growth demands it, rather than copying the infrastructure of a company operating at a vastly different scale.

Can Onclick Innovations help us choose the right technology stack for our product?

Yes. We help clients evaluate technology decisions based on their specific project requirements, team composition, timeline and growth plans rather than defaulting to a single preferred stack. Contact us at onclickinnovations.com to discuss your project.

Share

The post The Tech Stack Behind 6 Famous Apps: What Netflix, Uber, WhatsApp, Instagram, Spotify and Airbnb Are Actually Built With appeared first on Blog.

Database migrations are one of the highest-risk operations in software engineering. Done correctly, they are invisible — users notice nothing, data integrity is preserved, and the deployment is forgotten by the following morning. Done incorrectly, they produce the kind of incident that gets discussed in retrospectives for years.

We have been called in to help recover from database migrations gone wrong more times than we care to count. Every single time, the root cause traces back to the same pattern: someone skipped at least one step on this checklist.

Save this post. Share it with your engineering team. Run through it before every migration, regardless of how simple the change looks.

Why Database Migrations Go Wrong

The most dangerous migrations are not the complex ones. The most dangerous migrations are the ones that look simple.

A simple column rename. Adding a non-nullable field. Dropping a table that “nobody uses anymore.” Changing a data type from integer to bigint. These are the migrations that skip review, skip testing, and skip preparation — because they seem too straightforward to warrant it.

They are also the migrations most likely to cause extended downtime, data loss, or cascading failures that take hours to diagnose and recover from.

The checklist below applies to every migration. Simple or complex. Small table or large. Green field or legacy system. The steps do not change based on your confidence that this particular migration is “probably fine.”

The 8-Step Database Migration Checklist

1. Verified Backup — Not Assumed

Do not assume last night’s backup ran successfully. Verify it. This means confirming that the backup job completed, checking the backup file size against historical norms, and — critically — performing a test restore from the backup to a separate environment.

An untested backup is not a backup. It is hope.

This distinction matters because backup jobs fail silently. A misconfigured backup schedule, a full disk, a permission error, an expired credential — any of these can cause backup jobs to fail without triggering an alert. If your first test of a backup is during an active recovery from a failed migration, you have compounded one incident into two.

Before every migration: verify the backup exists, verify the restore works, and document when the verification was performed.

2. Dry Run on a Production Clone

Run the full migration against a copy of production data before running it against production itself. Not against your staging environment. Not against your development database. Against a clone of production.

This distinction is critical. Staging and development environments almost never contain representative production data. They lack the edge cases, the inconsistent historical records, the orphaned rows, the unexpected null values, and the sheer volume that production carries. A migration that completes in thirty seconds against fifty thousand staging rows can fail at four hours against fifty million production rows — for reasons that would have been immediately obvious on a production clone.

The dry run serves three purposes: it confirms the migration SQL is syntactically correct and logically sound, it surfaces data quality issues that will cause the migration to fail or produce incorrect results, and it gives you an accurate timing estimate for step four.

3. Written Rollback Plan

Before any migration runs, document exactly what you will do if it needs to be rolled back. This documentation must exist in written form — not in the head of the engineer running the migration, not as a verbal agreement, not as a plan you will figure out if something goes wrong.

The rollback plan should specify: the exact commands to execute, the order in which to execute them, who has the database access required to execute them, how long the rollback will take based on your dry run, and what the acceptance criteria are for a successful rollback.

If you discover during a failed migration that your rollback takes four hours, your team needs to have known that before the migration started — not when they are managing an active production incident at 2am.

4. Migration Timing Estimation

Every migration has a runtime. Know yours before the maintenance window begins.

Use the production clone from step two to time the migration accurately. Record the row count of affected tables, the total data volume, and the elapsed time. Extrapolate if your clone is a partial sample. Add a safety margin — production is never quite the same as a clone, and contention from live traffic will slow write operations.

Timing estimation matters for maintenance window planning, for customer communication, and for the rollback decision threshold. If your migration is expected to take forty-five minutes and it has been running for three hours, you need a defined threshold at which the team escalates to rollback rather than continuing to wait.

Define that threshold before you start. Not during.

5. Maintenance Window or Zero-Downtime Strategy

Every migration requires either a maintenance window or a zero-downtime strategy. There is no third option.

If your migration requires application downtime — because it involves a lock that blocks reads, or because it changes a schema that live application code cannot handle in its current state — plan the maintenance window explicitly. Define the start time, the expected end time, the rollback threshold, and who communicates status to affected users. Get approval from the appropriate stakeholders before the window begins.

If your migration cannot tolerate downtime, implement a zero-downtime strategy. Common patterns include the expand/contract approach (add new columns while keeping old ones, migrate data in batches, switch application code, then drop old columns), feature flags to gate new schema-dependent code paths, and shadow write patterns where data is written to both old and new schema simultaneously during the transition.

Choosing the wrong strategy — attempting a zero-downtime migration with code that requires a maintenance window, or taking unplanned downtime on a migration you thought would be online — is the single most common cause of extended production incidents during database migrations.

6. Monitoring and Alerting Live Before You Start

Have your monitoring dashboards open and your alerting configured before you execute the first migration command. Do not wait until you suspect something is wrong to open your monitoring tools.

The metrics to watch during a database migration include: error rates on application endpoints that touch the affected tables, database query execution times and lock wait times, replication lag if you are running read replicas, disk I/O and disk space consumption (large migrations generate significant write amplification), and application memory usage if your migration involves large result sets.

The difference between catching a problem at one minute versus ten minutes can be the difference between a brief blip and a multi-hour incident. Monitoring that you check after you suspect something is wrong is not monitoring. It is forensics.

7. Team Communication Plan

Before the migration starts, every team member involved should know the answers to these questions: Who is the primary engineer executing the migration? Who is the on-call escalation if the primary engineer needs support? Who has database access to execute a rollback? Who makes the decision to roll back, and at what threshold? Who communicates status to the business, and through what channel?

These questions feel obvious. They are not obvious at 2am during an active incident when the primary engineer is debugging a lock contention issue, the rollback decision is time-sensitive, and nobody is sure who has the database credentials to execute it.

Document the answers before the migration starts. Share the document with everyone in the migration channel. Confirm receipt.

8. Post-Migration Validation Queries

Write your validation queries before the migration runs, not after it completes.

Validation queries written after a successful migration are shaped by the assumption that the migration succeeded. Validation queries written before the migration are shaped by what you are actually trying to verify. These are not the same queries.

Your validation suite should include: row count comparisons between the state before migration and after, referential integrity checks on foreign key relationships, spot checks on specific records that represent critical business data, and functional checks that confirm the application behaves correctly against the migrated schema.

Run these queries immediately after migration completes. A migration that finishes without errors is not necessarily a successful migration. A migration where your validation suite passes is a successful migration.

The Pattern Behind Every Migration Incident

We have never been called to help recover from a database migration where the team ran through all eight steps and something still went catastrophically wrong. We have been called to recover from migrations where teams skipped one step — sometimes just one — and paid for it.

The conversation is always the same: “We thought it would be fine.”

It was not fine.

The migration checklist is not overhead. It is the difference between a migration that is boring and forgotten by the following morning, and a migration that becomes the case study in your next engineering retrospective.

“An untested backup is not a backup. It is hope. And hope is not an engineering strategy.”

How Onclick Innovations Handles Database Migrations

At Onclick Innovations, we treat every database migration as a production incident waiting to happen — until our checklist proves otherwise. This is not pessimism. It is the engineering discipline that has allowed us to migrate hundreds of production databases across 350+ projects without a single data loss incident.

Every migration we execute includes a verified backup, a dry run on a production clone, a written rollback plan with defined thresholds, an accurate timing estimate, a defined downtime or zero-downtime strategy, pre-configured monitoring, a team communication plan, and a pre-written validation suite.

For clients managing their own migrations, we provide migration review as part of our engagement — reviewing the migration plan, the rollback strategy, and the validation approach before the first command runs.

If you are planning a database migration and want a second set of experienced eyes on your approach, we are happy to help.

📩 Get in touch → www.onclickinnovations.com
📍 Based in Mohali, India · Serving clients globally across 10+ countries

Frequently Asked Questions

What is a database migration?

A database migration is any change to the structure or content of a production database — including adding or removing columns, changing data types, renaming tables, adding indexes, migrating data between tables or schemas, and upgrading database versions. Migrations range from trivial to extremely complex, but all carry risk when executed against live production data.

What is a production clone and why do I need one?

A production clone is an identical copy of your production database, created specifically for migration testing. It contains the same schema, the same data volume, and representative examples of the edge cases that exist in your live data. Running a migration dry run against a production clone gives you an accurate preview of how the migration will behave in production — including timing, any data quality issues, and potential failure modes that would never surface in staging or development.

What is the expand/contract pattern for zero-downtime migrations?

The expand/contract pattern is a technique for making breaking schema changes without application downtime. It involves three phases: expand (add the new schema element while keeping the old one, deploy application code that writes to both), contract phase one (migrate existing data to the new schema, verify, stop writing to the old schema), and contract phase two (remove the old schema element). Each phase is a separate deployment with validation between them, allowing the migration to proceed without any single deployment requiring downtime.

How long should I keep a backup before running a migration?

You should take a fresh backup immediately before running any production migration, regardless of your regular backup schedule. This backup should be verified by performing a test restore before the migration begins. Keep this pre-migration backup for at least 30 days after the migration completes, or longer if your business has regulatory requirements around data retention.

Can Onclick Innovations review our migration plan before we execute it?

Yes. We offer migration review as part of our engineering services — reviewing your migration SQL, rollback strategy, timing estimates, and validation approach before you touch production. Contact us at onclickinnovations.com to discuss your requirements.

Share

The post The Database Migration Checklist: 8 Things You Must Do Before Touching Production Data appeared first on Blog.

Published by Onclick Innovations · Software Development · June 2026 · 8 min read

A well-designed API is invisible. Developers consume it, build on top of it, and ship products faster because of it — without ever thinking about the API itself. A poorly designed API is the opposite. It generates support tickets, causes production incidents, and eventually gets rewritten by the team inheriting it.

After building over 350 production software products across fintech, healthcare, e-commerce and enterprise SaaS, we have seen what separates APIs that scale gracefully from APIs that become someone else’s most expensive maintenance problem.

This is the checklist we use internally at Onclick Innovations. Save it. Share it. Use it.

1. Versioning From Day One

Every API should be versioned from the first line of code. Not from the moment you need to make a breaking change — from day one.

The correct pattern is simple: /api/v1/users not /api/users. When you need to introduce a breaking change, /api/v2/ exists without disrupting any client currently integrated against /api/v1/.

Teams that skip versioning always face the same moment: the first time they need to change a response structure, they discover they cannot do it without breaking every client integration simultaneously. At that point the cost of adding versioning retroactively is significantly higher than it would have been from the start.

Versioning is the most important decision you make when designing an API. Everything else is recoverable. Versioning is not.

2. Consistent, Structured Error Responses

Every error your API returns should follow the same structure. Every single one. Without exception.

A well-structured error response contains at minimum:

• An HTTP status code that accurately reflects what happened
• A machine-readable error code (e.g. USER_NOT_FOUND, INVALID_EMAIL_FORMAT)
• A human-readable message that explains what went wrong
• A unique request ID for debugging and support correlation

What a bad API returns: 500 Internal Server Error with no body, or a generic message that gives the consuming developer no actionable information.

Consistent error responses are not just a developer experience concern. They directly reduce your support overhead. When every error contains a request ID, your support team can trace any reported issue in seconds instead of hours.

3. Rate Limiting on Every Endpoint

An API without rate limiting is one script away from being taken offline. Whether the cause is a well-intentioned developer running a loop, a misconfigured client retrying infinitely, or a deliberate attack — the result is the same: your API goes down for everyone.

Implement per-user and per-endpoint rate limits. When a limit is exceeded, return 429 Too Many Requests with a Retry-After header telling the client exactly when they can try again.

Good rate limiting strategy includes different tiers for different endpoint types. A read endpoint can be more generous than a write endpoint. A search endpoint with expensive database operations needs tighter limits than a simple lookup. Apply limits intentionally, not uniformly.

4. Authentication Done Right

There are three authentication patterns that cover the vast majority of API use cases in 2026:

• JWT (JSON Web Tokens) — for stateless authentication where the server does not need to store session state. Ideal for microservices and distributed systems.
• OAuth 2.0 — for third-party integrations where users grant your API access to resources in another system. The correct choice for any social login or third-party service integration.
• API Keys — for server-to-server communication where a trusted system is calling your API directly. Simple, auditable and effective for this specific use case.

The rule that matters most: never roll your own authentication. Cryptographic implementations have subtle edge cases that are extremely difficult to get right and catastrophic when you get wrong. Use established libraries and protocols. The cost of a security vulnerability in authentication code vastly exceeds the cost of using a well-maintained library.

5. Pagination on Every List Endpoint

No list endpoint should ever return an unbounded result set. Every endpoint that returns multiple records needs pagination implemented before it goes to production.

The two common approaches are offset-based pagination (?page=2&limit=20) and cursor-based pagination (?cursor=eyJ1c2VySWQiOjEwMH0). For most production use cases, cursor-based pagination is the superior choice. It performs consistently regardless of dataset size, handles records being added or deleted between pages correctly, and does not degrade as users page deeper into results.

Offset-based pagination is simpler to implement but degrades at scale. When a user requests page 500 of a 10,000-record dataset, the database must skip 9,980 records before returning 20. Cursor-based pagination retrieves only the records that need to be returned, regardless of position.

6. Idempotency Keys for Mutating Operations

Any endpoint that creates a resource, initiates a transaction or triggers an irreversible action should accept an idempotency key.

An idempotency key is a unique identifier sent by the client with their request. If the same request is submitted twice with the same idempotency key — due to a network timeout, a retry logic bug, or a double-click — the server returns the result of the first request instead of performing the operation twice.

This pattern is used by Stripe for every payment operation. It is used by every financial services API that handles money movement. It is the correct default for any operation that should not be duplicated.

Without idempotency keys, a client that retries a failed request due to a timeout may create duplicate records, charge a customer twice, or trigger duplicate notifications. The cost of implementing idempotency keys is small. The cost of not implementing them is measured in production incidents and customer complaints.

7. Request Validation With Specific Error Messages

Validate all input at the API layer before it touches your database or business logic. This means checking types, formats, required fields, value ranges and cross-field constraints.

When validation fails, return exactly what failed and why. Not 400 Bad Request. Not "Invalid input". Something like:

{"field": "email", "error": "INVALID_FORMAT", "message": "The email address provided is not a valid format."}

Specific validation errors eliminate entire categories of back-and-forth between developers integrating your API and your support team. They also reduce incorrect data reaching your database, which prevents a much larger class of downstream problems.

8. Comprehensive Documentation

If a developer needs to read your source code to understand how to use your API, your API has failed. Full stop.

Great API documentation includes:

• An OpenAPI or Swagger specification that is always up to date and generated from the code itself
• A working example for every single endpoint
• Authentication setup instructions that a developer can follow without prior context
• A clear explanation of every error code the API can return
• A changelog that documents what changed between versions and why

Documentation that is maintained separately from the codebase goes out of date. The correct approach is to generate documentation automatically from the code — tools like Swagger UI, Redoc and Stoplight all support this pattern. When the code changes, the documentation changes with it.

9. Logging and Observability

You cannot debug what you cannot see. Every API request should produce a structured log entry containing at minimum: timestamp, user or API key identifier, endpoint called, HTTP method, response status code, response time in milliseconds, and the request ID that appears in any error responses.

Beyond basic logging, production APIs need distributed tracing for requests that span multiple services, metrics on response time percentiles (p50, p95, p99 — not just averages), and alerting on error rate thresholds.

The teams that build observability in from the start spend dramatically less time debugging production incidents. The teams that treat it as something to add later find themselves flying blind at the worst possible moment.

10. Graceful Degradation

In a distributed system, dependencies fail. Third-party services go down. Databases become temporarily unavailable. Internal microservices return unexpected errors.

A well-designed API handles these failures gracefully. When a non-critical dependency fails, the API returns a partial response rather than a complete failure. When a cache is unavailable, the API falls back to the database with a performance warning rather than returning an error. When a downstream service is degraded, the API returns cached data with a staleness indicator rather than a 500.

The pattern to implement is the circuit breaker: monitor failure rates on dependencies, and when they exceed a threshold, stop sending requests to the failing service temporarily and return a cached or degraded response instead. This prevents one failing service from cascading into a complete system outage.

Graceful degradation is the difference between an incident that users notice and an incident that your monitoring catches before users do.

The Pattern Behind Every Item on This List

Every item on this checklist follows the same logic: the cost of implementing it correctly from the start is small, and the cost of not implementing it is paid repeatedly and unpredictably over the lifetime of the API.

The APIs we have inherited that had none of these things always came with the same story: “We built it fast and planned to fix it later.”

Later never comes. Instead, the team inheriting the API spends six months firefighting rather than building new features. The product stagnates. The technical debt compounds. Eventually someone makes the case for a full rewrite — at ten times the cost of building it correctly the first time.

“Fixing a bad API costs 5× more than building a good one. We have seen this enough times to know it is not an exaggeration.”

How Onclick Innovations Builds APIs

Every API we build at Onclick Innovations ships with all ten of these properties as a baseline. Not as extras. Not as a premium tier. As the standard.

Versioning is designed into the routing from the first commit. Error responses follow a consistent schema defined at project kickoff. Rate limiting is configured before the first endpoint goes to production. Authentication uses established protocols, not custom implementations. Documentation is generated automatically from the OpenAPI spec and kept in sync with the codebase.

We have built APIs for fintech platforms handling millions of transactions, healthcare systems managing sensitive patient data, e-commerce platforms processing high-volume order flows, and enterprise SaaS products serving thousands of concurrent users across multiple regions.

The pattern is consistent across all of them: APIs built with these ten properties require dramatically less maintenance, generate fewer support escalations, and support faster feature development than APIs that treat these properties as optional.

📩 Get in touch → www.onclickinnovations.com
📍 Based in Mohali, India · Serving clients globally across 10+ countries

Frequently Asked Questions

What is API versioning and why does it matter?

API versioning is the practice of including a version identifier in your API’s URL structure (e.g. /api/v1/) so that breaking changes can be introduced in a new version without disrupting existing client integrations. It matters because APIs, once consumed by external clients, become contracts. Without versioning, any breaking change breaks every client simultaneously.

What is an idempotency key in API design?

An idempotency key is a unique identifier sent by a client with a mutating API request. If the same request is submitted multiple times with the same idempotency key, the server returns the result of the first successful request rather than performing the operation again. This prevents duplicate records, double charges and duplicate notifications caused by network timeouts and retry logic.

What is the difference between offset and cursor-based pagination?

Offset pagination uses a page number and page size to determine which records to return (e.g. skip 40, take 20). Cursor-based pagination uses a pointer to the last record seen to determine the next page. Cursor-based pagination performs consistently at scale and handles records being added or deleted between pages correctly, making it the preferred approach for production APIs with large datasets.

What authentication method should my API use?

The right authentication method depends on your use case. Use JWT for stateless authentication in single-service or microservices architectures. Use OAuth 2.0 when users need to grant your API access to resources in a third-party system. Use API keys for server-to-server communication. Never implement custom cryptographic authentication — use established libraries and protocols.

How does Onclick Innovations approach API design?

We build all ten of these properties into every API from day one as a baseline standard. We use OpenAPI specifications to keep documentation in sync with the codebase automatically, implement cursor-based pagination on all list endpoints, and use established authentication protocols across all integrations. Contact us at onclickinnovations.com to discuss your API requirements.

Share

The post API Design Checklist: 10 Things Every Great API Has appeared first on Blog.