No major rewrite has replaced it. No well-funded startup has dethroned it. Every serious alternative that’s launched since — and there have been several — has ended up either wrapping Git, integrating with Git, or quietly fading out. In an industry that reinvents itself every eighteen months, that kind of staying power is worth asking about.

Built Out of Frustration, Not Ambition

Git wasn’t built as a product. It was built because the Linux kernel team lost access to the proprietary tool (BitKeeper) they’d been using, and Torvalds needed a replacement fast — one that could handle a codebase with thousands of contributors and no central authority forcing everyone to work the same way.

That constraint shaped everything about how Git works. It had to be distributed, because Linux kernel development has never had one central server everyone depends on. It had to be fast, because kernel commits happen constantly. And it had to trust developers to work independently and merge later, rather than requiring permission before every change.

Those weren’t marketing decisions. They were survival decisions for one specific, enormous open-source project. It just turned out that nearly every software team on Earth had the same underlying problem.

What Actually Makes Git Different

Version control existed before Git. CVS, Subversion, and Perforce were all in wide use in 2005. What set Git apart wasn’t that it tracked changes — it was how it tracked them.

• Fully distributed. Every developer’s local copy is a complete repository with full history, not a thin client talking to a central server. You can commit, branch, and view history with zero network connection.
• Cheap, fast branching. Creating a branch in older systems could be a slow, heavyweight operation. In Git, it’s close to instant, which is what made feature branches, pull requests, and modern code review workflows practical in the first place.
• Content-addressed storage. Git identifies every piece of data by a hash of its content, not by filename or location. That’s the underlying reason Git is so good at detecting duplicate content, verifying integrity, and handling merges intelligently.
• No single point of failure. Because every clone is a full repository, losing the server doesn’t mean losing the project. Any developer’s machine can restore the whole history.

None of these ideas were entirely new in computer science. What Git did was combine them into a tool fast and reliable enough that teams stopped thinking about version control as a constraint and started treating it as infrastructure they didn’t need to worry about.

GitHub Didn’t Make Git Popular — It Made Git Social

It’s a common mix-up: many developers who started their careers after 2010 assume Git and GitHub are basically the same thing. They’re not. Git is the version control system running on your machine. GitHub, launched in 2008, is a hosting platform built on top of it.

What GitHub actually did was take Git’s distributed model and add a social and collaborative layer on top: pull requests, code review threads, issues, forks you could contribute back from, and eventually a de facto resume for developers. GitLab and Bitbucket followed with their own takes on the same idea.

That combination — Git’s technical model plus a platform for open collaboration — is arguably what pushed Git from “the tool Linux uses” to the default choice for nearly every kind of software project, open source or private.

Every Attempt to Replace It Has Failed — Or Just Joined It

Git has had real competition. Mercurial launched the same year as Git and, for a while, was considered by many to have a friendlier command-line interface. Some large companies, including Facebook for a period, invested heavily in alternatives or in heavily customized Git internals (Facebook eventually built Sapling, and Google has long used a modified, monorepo-focused workflow).

None of these efforts displaced Git at the industry level. The pattern that keeps repeating is telling: companies that need something different from stock Git tend to build tooling on top of Git rather than replace it outright. The underlying object model and distributed design have proven durable even when the workflow layered on top changes completely.

The Learning Curve Nobody Talks Their Way Out Of

Ask almost any developer, junior or senior, and you’ll hear some version of the same story: Git was confusing at first. Commands like rebase, cherry-pick, and reflog are genuinely hard to reason about the first time you encounter them, and a botched merge can still produce a moment of real panic.

That difficulty is part of why Git has stayed relevant rather than a reason it should have been replaced. The complexity isn’t accidental — it’s the visible surface of a genuinely powerful underlying model. Once a developer understands what a commit, a branch, and a merge actually represent internally, the commands stop feeling arbitrary and start feeling like direct, honest access to the data. Tools that hide that complexity behind friendlier interfaces tend to work fine until something goes wrong, at which point understanding the Git model underneath becomes the only way out.

Why Git Survived the AI Coding Wave

2026 has brought a wave of AI coding assistants, autonomous coding agents, and AI-native development workflows. It would have been reasonable to expect version control itself to get reinvented along with everything else.

Instead, AI coding tools have overwhelmingly built on top of Git rather than around it. AI agents commit through Git. Code review tools built for AI-generated pull requests still rely on Git’s diff and merge model. Even tools designed to let AI agents work autonomously across a codebase use Git branches and commits as the underlying record of what changed and why.

That’s not a coincidence. Git’s content-addressed, immutable history is exactly the kind of structure that makes it possible to track, audit, and roll back AI-generated changes with confidence — something that matters more, not less, as more code gets written by autonomous agents rather than humans typing directly.

What 21 Years of Git Says About Good Infrastructure

Git’s longevity says something bigger about how durable technical decisions actually work. It wasn’t designed to be a product, to be easy to learn, or to win a popularity contest. It was designed to solve one hard, specific problem correctly, at scale, under real constraints.

Software teams evaluating new tools and frameworks in 2026 are often chasing the newest option. Git is a reminder that the tools with the longest lifespans are usually the ones built to solve a real structural problem well, not the ones built to be trendy. Frameworks come and go. The version control layer underneath them has stayed remarkably stable for over two decades.

At Onclick Innovations, every project we build — regardless of the framework, language, or client industry — runs on Git. It’s one of the few pieces of the stack we never have to debate.

Frequently Asked Questions

How old is Git in 2026?
Git was created by Linus Torvalds in April 2005, making it 21 years old in 2026.

Why was Git created?
Git was built because the Linux kernel development team lost access to the proprietary version control tool they had been using and needed a fast, distributed replacement capable of handling a massive, decentralized open-source project.

Is Git the same thing as GitHub?
No. Git is the version control system itself, run locally on a developer’s machine. GitHub is a hosting platform, launched in 2008, built on top of Git that adds collaboration features like pull requests and issue tracking. GitLab and Bitbucket are similar hosting platforms.

Has anything replaced Git?
No mainstream alternative has replaced Git at an industry level. Some large companies have built customized tooling on top of Git’s core model for specific needs, but Git itself remains the dominant underlying version control system.

Why does Git still matter in the age of AI coding tools?
AI coding assistants and autonomous coding agents in 2026 are built on top of Git rather than replacing it, because Git’s immutable, content-addressed history makes it possible to track, audit, and roll back AI-generated code changes reliably.

Share

The post Git Just Turned 21 — Here’s Why Every Developer Still Can’t Escape It appeared first on Blog.

In that quarter of a second, an extraordinary sequence of events takes place across your device, multiple servers scattered around the planet, and several layers of internet infrastructure that most people never think about. This is the story of everything that happens in that invisible journey — from keystroke to pixel.

The Illusion of Instant

Modern browsing feels instant. That feeling is an illusion carefully engineered by decades of infrastructure investment, protocol optimisation and clever caching. Underneath that illusion is a genuinely complex pipeline involving your operating system, your router, your internet service provider, global naming systems, distant servers, and your browser’s rendering engine — all cooperating in milliseconds.

Understanding this pipeline is not just academic curiosity. It is one of the most useful mental models a developer, founder or technical decision-maker can have, because nearly every performance problem, security consideration and infrastructure cost in web development traces back to one of these steps.

Here is exactly what happens, step by step, from the moment you press Enter.

Step 1: Parsing What You Typed (0–1ms)

Before anything travels anywhere, your browser has to figure out what you actually typed. Modern address bars accept search terms, partial URLs and full addresses interchangeably, so the browser first determines whether your input is a valid URL or a search query destined for your default search engine.

If it is a URL, the browser parses it into its component parts: the protocol (http or https), the domain name, the path, and any query parameters. This happens locally, in well under a millisecond, before any network activity begins.

Step 2: The DNS Lookup (0–120ms)

Computers do not naturally know that “google.com” corresponds to a specific server. They need an IP address — a numerical identifier like 142.250.190.78. Translating a human-readable domain name into that IP address is the job of DNS, the Domain Name System, often described as the phone book of the internet.

The lookup process follows a specific order, checking increasingly slower caches until it finds an answer. First, the browser checks its own DNS cache — if you have visited this site recently, the answer may already be stored locally, and this step completes in under a millisecond. If not, the browser checks the operating system’s DNS cache, then potentially a local router’s cache.

If none of these have an answer, the request travels to a DNS resolver — typically operated by your internet service provider or a public resolver like Google’s 8.8.8.8 or Cloudflare’s 1.1.1.1. This resolver may need to query a chain of authoritative servers: first a root server, then a top-level domain server (responsible for all “.com” domains, for instance), then finally the authoritative server for the specific domain, which returns the actual IP address.

A cold DNS lookup with no caching anywhere in the chain can take anywhere from 20 to 120 milliseconds — a significant portion of your total 300 millisecond budget, spent before a single byte of the actual website has been requested. This is precisely why DNS caching, and services like DNS prefetching, matter so much for perceived site speed.

Step 3: The TCP Handshake (20–100ms)

With an IP address in hand, your browser now needs to establish a reliable connection to that server. Most web traffic runs over TCP, the Transmission Control Protocol, which guarantees that data arrives complete, in order, and without corruption — a critical property for something as detail-sensitive as a web page.

Establishing a TCP connection requires what is known as a three-way handshake. Your browser sends a SYN (synchronize) packet to the server, essentially saying “I’d like to start a conversation.” The server responds with a SYN-ACK packet, acknowledging the request and proposing its own synchronization. Your browser then sends a final ACK packet, confirming the connection is established.

Each of these three packets has to physically travel across the network — through your router, your ISP, and potentially dozens of intermediate hops — before the next one can be sent. This round-trip time, often abbreviated as RTT, depends heavily on physical distance. A server on the other side of the world will always have a higher minimum TCP handshake time than one in a nearby data centre, no matter how well-optimised the software is, because the packets are limited by the speed of light through fibre optic cable.

Step 4: The TLS Negotiation (30–100ms)

If the connection uses HTTPS — which the overwhelming majority of the modern web does — an additional negotiation happens immediately after the TCP handshake completes. This is the TLS (Transport Layer Security) handshake, and it is responsible for the encryption that keeps your data private and verifies you are actually talking to the server you think you are.

During this negotiation, your browser and the server agree on which encryption protocols and cipher suites they will use, the server presents a digital certificate proving its identity (issued by a trusted certificate authority), and both sides generate the cryptographic keys that will encrypt all subsequent communication. Modern TLS 1.3, now the dominant standard, reduced this from two round trips down to effectively one, meaningfully cutting the time this step takes compared to older TLS versions.

By the end of this step, you have a secure, authenticated, encrypted channel open to the server — and you still have not received a single byte of the actual web page.

Step 5: The HTTP Request and Server Processing (10–200ms)

With the secure connection established, your browser finally sends the actual HTTP request — specifying which page it wants, along with headers describing your browser, accepted content types, cookies, and other metadata.

What happens next depends entirely on how the destination server is built. For a simple static site, the server might locate a pre-built HTML file and return it almost instantly. For a dynamic application, the server typically needs to run application code, which might query one or more databases, call external APIs, apply business logic, and assemble a response — all before sending anything back.

This is the step where backend architecture decisions have the most visible impact. A well-indexed database query might add 5 milliseconds. A poorly optimised one, missing the right index or fetching far more data than needed, can add hundreds of milliseconds all on its own. This is also where server-side caching, content delivery networks and edge computing earn their keep — by serving pre-computed or cached responses instead of repeating expensive work for every single request.

Step 6: Receiving the Response and Parsing HTML (5–20ms)

The server’s response arrives, typically starting with an HTML document. Your browser does not wait for the entire page to arrive before beginning work — it starts parsing the HTML as bytes stream in, building what is called the DOM, or Document Object Model: a structured tree representation of every element on the page.

As the parser encounters references to additional resources — CSS stylesheets, JavaScript files, images, fonts — it typically kicks off requests for those resources immediately, often in parallel, rather than waiting for the full document to finish downloading first. This parallelism is a major reason modern pages load faster than a naive step-by-step model would suggest.

Step 7: Building the Render Tree and Layout (5–30ms)

Once enough CSS has arrived, the browser combines the DOM with the CSS Object Model (the parsed representation of your stylesheets) to produce what is called the render tree — essentially the DOM, but annotated with exactly how each element should look.

The browser then performs what is called layout, or reflow: calculating the precise size and position of every single element on the page, accounting for the viewport size, box model rules, flexbox and grid layouts, and every CSS rule that affects geometry. This is genuinely one of the more computationally expensive steps in the entire pipeline, which is why excessive dynamic layout changes are a common cause of janky, sluggish-feeling web pages.

Step 8: Painting and Compositing (5–20ms)

With layout complete, the browser moves to painting — converting the render tree into actual pixels, filling in colours, text, images, borders, shadows and every other visual detail. Modern browsers optimise this further through compositing, where different layers of the page (an animated element, a fixed header, a video player) are rendered independently on the GPU and combined at the final moment, allowing smooth animations and scrolling without repainting the entire page from scratch.

This is the step where your screen finally shows something. On a fast connection with an optimised site, everything from the initial DNS lookup to this final paint can complete in well under 300 milliseconds — fast enough that the entire journey feels instantaneous to a human brain.

Why Every Millisecond in This Chain Matters

Google has published research showing that even small increases in page load time measurably increase bounce rates and decrease conversions. Amazon has cited internal data suggesting that every 100 milliseconds of additional latency measurably impacts revenue. These are not abstract engineering concerns — they are direct business outcomes tied to exactly the pipeline described above.

Every step in this journey represents an opportunity for optimisation, and every step represents a potential point of failure or slowdown if built carelessly. DNS prefetching, connection pooling, HTTP/2 and HTTP/3 multiplexing, TLS session resumption, database query optimisation, CDN edge caching, code splitting, lazy loading and critical rendering path optimisation are all, at their core, techniques aimed at shortening one specific step in this exact pipeline.

What This Means for Anyone Building Software

Understanding this journey changes how you think about performance. A slow page is never just “slow” in some vague sense — it is slow at a specific, identifiable step. Maybe DNS resolution is taking too long because there is no caching strategy. Maybe the TCP and TLS handshakes are slow because the server is geographically distant from most users, with no CDN in front of it. Maybe the server processing step is slow because of an unoptimised database query. Maybe the rendering step is slow because of render-blocking JavaScript or excessive layout recalculation.

Each of these has a specific, well-understood fix. But you can only apply the right fix once you understand which step in the pipeline is actually the bottleneck — which is exactly why this invisible 300-millisecond journey is worth understanding in detail, not just accepting as web browsing magic.

How Onclick Innovations Builds for Speed

At Onclick Innovations, performance is not an afterthought we address after launch — it is a consideration at every step of this pipeline, built in from the start. We implement CDN strategies to shorten physical distance to users, optimise database queries and indexing to keep server processing fast, apply modern HTTP protocols and TLS configurations to minimise handshake overhead, and build frontend code with the critical rendering path in mind.

The result is software that feels instant — because every millisecond in this 300-millisecond journey has been considered, measured and optimised.

If your website or application feels slower than it should, we are happy to help identify exactly which step in this pipeline is the bottleneck.

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

Frequently Asked Questions

What is a DNS lookup and why does it take time?

A DNS lookup translates a human-readable domain name like “example.com” into the numerical IP address computers use to locate a server. It takes time because, without caching, the request may need to travel through multiple servers — a resolver, a root server, a top-level domain server, and finally the domain’s authoritative server — each adding network round-trip time. Caching at the browser, operating system or router level can reduce a 100+ millisecond lookup to under a millisecond.

Why does HTTPS make websites slower than HTTP?

HTTPS requires an additional TLS handshake after the TCP connection is established, adding one or more network round trips to negotiate encryption before any page data is transferred. Modern TLS 1.3 has significantly reduced this overhead compared to older versions, and the security benefits far outweigh the small latency cost — which is typically tens of milliseconds, not a noticeable delay to users.

What is the biggest factor in how fast a website loads?

There is no single biggest factor — it depends on the specific site. Common major contributors include server response time (often tied to database query performance), geographic distance between the user and server (addressed by CDNs), unoptimised images and assets, render-blocking JavaScript and CSS, and inefficient rendering caused by excessive dynamic layout changes. Identifying the actual bottleneck for a specific site requires performance profiling rather than guessing.

What is the difference between the DOM and the render tree?

The DOM (Document Object Model) is the browser’s structural representation of the HTML document — every element and its relationship to other elements. The render tree combines the DOM with CSS styling information, representing only the elements that will actually be visually displayed, along with how each one should look. The render tree is what the browser uses to calculate layout and eventually paint pixels to the screen.

Can Onclick Innovations help improve our website’s load time?

Yes. We analyse performance across the entire request pipeline — from DNS and connection setup through server processing and frontend rendering — to identify the specific bottlenecks affecting your site and implement targeted fixes. Contact us at onclickinnovations.com to discuss your project.

Share

The post What Actually Happens When You Type a URL and Hit Enter appeared first on Blog.

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.

One of the biggest mistakes founders, CTOs, and product teams make is assuming that if software is working, it is ready for production.

But those two things are very different.

“Working” means the software can perform the expected task in a controlled environment.

“Production-ready” means the software can survive real users, real data, real traffic, real failures, and real business pressure.

This gap is where many software projects fail.

What “Working” Software Really Means

When a feature is working, it usually means it does what it is supposed to do under ideal conditions.

• It works on the developer’s machine.
• It works with test data.
• It works when the user follows the expected path.
• It works when all third-party services are available.
• It works when only one person is using it.

That is useful, but it is not enough.

A working feature can still break under real-world conditions. It may look good in a demo, pass basic testing, and still fail badly once actual users start depending on it.

What Production-Ready Software Actually Means

Production-ready software is built for real business use. It is not just about whether the main feature works. It is about whether the entire system can operate reliably, securely, and predictably after launch.

Production-ready software should be able to:

• Handle many users at the same time.
• Accept bad input without crashing.
• Fail gracefully when dependencies go down.
• Log important errors so issues can be debugged quickly.
• Recover from failures without losing data.
• Protect against common security risks.
• Monitor performance and errors before users complain.
• Support safe deployment, rollback, and future updates.
• Be understandable for developers who did not originally build it.

That is the real difference.

Working software proves that an idea can function. Production-ready software proves that a business can depend on it.

The Difference Between a Demo and a Business

A demo is usually built around the happy path. The user clicks the right buttons, enters valid data, and everything behaves as expected.

A real product is different.

Users enter unexpected data. Networks fail. Payment providers go down. Servers slow down. APIs time out. Databases receive duplicate requests. Bots attack forms. A new deployment breaks something that was working yesterday.

This is why production readiness matters.

The real test of software is not whether it works when everything goes right. The real test is whether it behaves safely when something goes wrong.

Real Examples of Software That Was “Working” but Not Production-Ready

1. The Payment Flow That Charged Users Twice

The payment flow worked perfectly during testing. One user clicked “Pay,” the transaction went through, and the order was created.

But in production, two requests came in at almost the same time. The system did not handle duplicate transactions properly, and the customer was charged twice.

The feature was working. It was not production-ready.

2. The Login System That Crashed on Unexpected Input

The login system worked with normal usernames and passwords. But when a user entered an unusual character, such as an emoji, the system failed because input validation and database handling were not strong enough.

A production-ready system should expect unexpected input. It should validate, sanitize, reject, or safely process data without taking down the application.

3. The App That Failed on Launch Day

The application looked smooth in the demo. Pages loaded quickly, the interface worked, and the product felt ready.

Then launch day came. Hundreds of real users opened the app at the same time, and pages started taking 30 to 45 seconds to load.

The app worked in testing, but it had not been designed or tested for scale.

4. The API That Failed When a Third-Party Service Went Down

The API worked well as long as every dependency was available. But when one third-party service went offline, the entire application stopped responding.

A production-ready system should not collapse completely because one external service fails. It should use timeouts, retries, fallback behavior, and graceful error handling.

5. The Feature That Broke Silently

A new feature was released on Friday. It appeared to work, and the team moved on.

By Monday, users had already experienced problems, but nobody on the team knew because there was no monitoring, no alerting, and no visibility into the failure.

Production-ready software does not depend on users to report every problem. It should detect issues early through monitoring, logging, and alerts.

Why Rushing to “Working” Becomes Expensive

The most expensive software is often not the software that takes longer to build properly.

The most expensive software is the software that has to be rebuilt because the first version was rushed to “working” and called complete.

When production readiness is ignored, the cost usually appears later in the form of:

• Emergency bug fixes
• Lost customer trust
• Failed launches
• Security vulnerabilities
• Data loss
• Poor performance
• Developer confusion
• Expensive rewrites

Many teams think they are saving time by skipping error handling, monitoring, documentation, scalability planning, and security review.

In reality, they are often moving the cost from development time to business risk.

A Simple Production-Ready Software Checklist

Before calling any feature complete, ask these questions:

• What happens if two users perform the same action at the same time?
• What happens if the user enters invalid or unexpected data?
• What happens if a third-party API is slow or unavailable?
• What happens if the database request fails?
• What happens if traffic suddenly increases?
• Can we detect errors before users complain?
• Can we roll back safely if something breaks?
• Is sensitive data protected properly?
• Can another developer understand and maintain this code?
• Is the system documented well enough for future changes?

If the answer to these questions is unclear, the software may be working, but it is not fully production-ready.

Production-Ready Software Is a Business Decision

Production readiness is not just a technical concern. It is a business decision.

For founders and CTOs, the goal is not only to launch fast. The goal is to launch in a way that can support users, protect the business, and create a foundation for growth.

A product that only works in a demo may impress people for a moment.

A product that is production-ready can support customers, revenue, operations, and long-term growth.

Working is the starting point. Production-ready is the standard.

How Onclick Innovations Builds Production-Ready Software

At Onclick Innovations, “working” is never the finish line.

We build software with production readiness in mind from day one. That means error handling, monitoring, security, scalability, clean architecture, and documentation are not treated as afterthoughts.

They are part of the foundation.

Whether you are building a startup MVP, a SaaS platform, a custom web application, an internal business tool, or a scalable digital product, the difference between “working” and “production-ready” can decide how reliable your product becomes after launch.

If you need developers who can build beyond the demo, Onclick Innovations can help.

Visit: www.onclickinnovations.com

Share

The post “It’s Working” and “It’s Production-Ready” Are Not the Same Thing 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.

Nobody tweets that checkout was seamless. Nobody calls support to say everything worked perfectly. Nobody posts a five-star review of the payment gateway because it processed their transaction in 180 milliseconds without a single hiccup.

The silence is the success.

This is the central paradox of great software engineering — and it is one that most people outside of engineering never fully grasp. The best software is invisible. Users never notice it working. They only notice when it breaks.

The Invisible Software Running the World Right Now

Before we talk about what invisible software looks like in practice, consider the scale at which it already operates around you.

Air traffic control software coordinates approximately 45,000 flights every single day. When was the last time you thought about the software keeping those planes separated? You haven’t. Because it works. The moment it stops working — a single incident in 2023 grounded thousands of US flights when a safety database file corrupted — it becomes the only thing anyone talks about.

Payment rails process over $500 trillion in transactions every year. The entire global economy moves through software that most people cannot name and have never thought about. When your card is declined because of a processing error, you notice immediately. When it processes in 180 milliseconds as it has ten thousand times before, you do not notice at all.

Traffic light systems operate in cities used by over four billion people daily. The timing algorithms that prevent gridlock and reduce accidents run continuously, invisibly, without acknowledgement. When a traffic light fails and an intersection grinds to a halt, it makes local news. When it works, it is furniture.

The scroll on your iPhone was engineered by a team that spent months ensuring it responds to exactly 60 frames per second — the threshold at which human perception stops distinguishing software from physics. You do not think “this scroll feels good.” You think “this phone feels good.” The engineering disappears into the experience.

This is what invisible software looks like at scale. And it is the standard that every piece of software should aspire to.

What Makes Software Invisible

Invisible software is not the result of clever code. Clever code gets noticed — usually by the developer who inherits it, at 2am, during a production incident they cannot diagnose because the original author was too clever to write comments.

It is not the result of impressive architecture. Nobody using Uber cares about their microservices topology. Nobody using Notion cares about their block-based data model. They care that the product works the way they expect it to work, every time they use it.

It is not beautiful design alone. A stunning interface that takes six seconds to load on a standard mobile connection is not invisible — it is conspicuous. Every user who watches a spinner is noticing your software in the worst possible way.

Invisible software is the result of something less glamorous and more demanding than any of these things:

Obsessive Attention to Edge Cases

The scenarios nobody thought to test are always the ones that surface in production. The user who pastes a 10,000-character string into a name field. The customer who submits a form by pressing Enter twice in rapid succession. The API client that retries a failed request without an idempotency key and creates duplicate records. The database query that performs beautifully on 10,000 rows and catastrophically on 10,000,000.

Invisible software handles these cases gracefully, silently, and without the user ever knowing they triggered an edge condition at all.

Performance Work That Makes Fast Feel Instantaneous

There is a threshold in human perception below which speed stops being a feature and becomes physics. Below about 100 milliseconds, a response feels immediate. Below 60 frames per second in animation, motion feels mechanical rather than natural. Below the threshold of noticeability, software becomes part of the environment.

The performance work that pushes software below these thresholds is some of the most demanding and least celebrated engineering that exists. It requires deep knowledge of how browsers render, how databases execute query plans, how networks introduce latency, and how human perception works. It produces software that people describe as “feeling right” without being able to say why.

Error Handling So Graceful Users Never See Errors

Every system fails. The question is whether the failure is visible to the user or invisible to them. Invisible software anticipates failures and handles them before they surface. A failed API call is retried with exponential backoff. A slow database query returns cached data with a freshness indicator. A third-party service going down triggers a circuit breaker that serves a degraded but functional experience rather than an error page.

Users experiencing invisible error handling do not know anything went wrong. They experience a slightly slower response, or a cached result, or a simplified interface. They do not experience a 500 error, a blank screen, or a lost form submission.

Infrastructure That Scales Before It Needs To

The viral moment, the press mention, the unexpected traffic spike from a social media post — these events do not announce themselves in advance. Invisible software is built for the traffic it does not yet have, so that when the traffic arrives, nobody notices the transition. The load balancers scale. The database read replicas absorb the increase. The CDN serves the static assets from edge locations near each user. The experience remains exactly the same at ten users and ten thousand.

Teams That Celebrate Zero Incidents

Perhaps the most important ingredient in invisible software is cultural rather than technical. Teams that treat a quiet week as a success — that celebrate the absence of incidents rather than only acknowledging heroic responses to them — build differently than teams that treat firefighting as the norm.

The heroic engineer who stays up all night fixing a production crisis is visible and celebrated. The methodical engineer who prevents the crisis from occurring through careful design, thorough testing, and comprehensive monitoring is invisible. Their best work is the absence of a story.

The Paradox of Great Engineering

This creates a genuine paradox for engineering teams and the businesses that employ them. The easiest engineering work to see and celebrate is the work done in response to failure. The hardest work to see and celebrate is the work that prevents failure.

Your best work is the work nobody ever talks about.

Your worst work is the work everybody is talking about.

This paradox shows up in how engineering teams are evaluated, how software projects are estimated, and how technical decisions get made under pressure. The features that users can see and comment on get prioritised. The reliability work that keeps those features working invisibly gets treated as optional, deferrable, something to address in a future sprint that never arrives.

The result is software that is visible in all the wrong ways. The loading spinner. The error message. The lost form submission. The 3am incident that interrupts someone’s weekend. The rollback that takes a feature users depend on offline for four hours.

“The goal of great engineering is not to be noticed. The goal is to be trusted.”

Measuring Success by What Does Not Happen

At Onclick Innovations, we have spent over a decade building software across fintech, healthcare, e-commerce, logistics and enterprise SaaS. 350+ products shipped. Clients across 10+ countries.

The metric we pay most attention to is not the one most clients ask about first. It is not features delivered per sprint, or velocity, or lines of code, or even uptime percentage.

It is this: what did not happen.

No 3am incidents. No rollbacks. No “it worked on staging.” No “we’ll fix it in the next sprint” carrying over for three quarters. No “the database went down because of a query we didn’t optimise.” No “we lost data because we didn’t account for that edge case.”

The absence of these events is the product of the engineering choices made before any code is written. The architecture review that catches the single point of failure before it becomes a production incident. The load test that surfaces the database query that performs fine at 1,000 records and destroys performance at 1,000,000. The error handling design that ensures a third-party service going down does not take the entire application with it.

This work is invisible by design. And that invisibility is the measure of its success.

What This Means for Businesses Building Software

If you are building a software product — whether it is a customer-facing application, an internal tool, or the infrastructure that runs your business — the most important question you can ask your engineering team is not “what are we building next?”

It is “what are we preventing?”

The most powerful thing you can build is software that people forget exists. Not because it is unimportant — but because it works so reliably, so quietly, so consistently, that it becomes part of the environment. It becomes infrastructure. It becomes the thing your business runs on without thinking about it.

That is the goal. Not to be noticed. To be trusted.

The software that achieves this is not built by accident. It is built by teams that have internalised the paradox of great engineering — that the work most worth doing is often the work that, if done correctly, nobody will ever see.

How Onclick Innovations Builds Invisible Software

Every product we build at Onclick Innovations is designed to be invisible in the ways that matter.

We build error handling before we build features. We load test before we go to production. We design for the traffic we do not yet have. We write the monitoring that catches problems before users do. We build the retry logic that handles the failed API call the user never sees. We design the database schema for the query patterns that will matter at scale, not just the patterns that matter today.

We celebrate quiet weeks. We treat an absence of incidents as the measure of a week well spent. We build software that people forget exists — because they are too busy using it to build their business.

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

Frequently Asked Questions

What does “invisible software” mean?

Invisible software refers to software that works so reliably and seamlessly that users never consciously notice it. They only become aware of it when it fails. The concept captures the highest standard of software engineering — not impressive features, but flawless, unnoticed reliability.

Why do users only notice software when it breaks?

Human attention is naturally drawn to anomalies and disruptions. When software works as expected, it becomes part of the background — like electricity or running water. When it fails, it immediately becomes foreground. This is why great software engineering focuses as much on preventing failure as on building features.

What are examples of invisible software?

Air traffic control systems coordinating 45,000 daily flights, payment rails processing $500 trillion annually, traffic light timing algorithms operating in cities used by billions, and the 60fps scroll on modern smartphones are all examples of invisible software — engineering so reliable it disappears into the experience.

How does Onclick Innovations build reliable software?

We build error handling before features, load test before production, design for future scale from day one, implement monitoring that catches problems before users encounter them, and measure success by the absence of incidents as much as by the presence of delivered features. Contact us at onclickinnovations.com to discuss your project.

What is the difference between good software and great software?

Good software does what it is supposed to do. Great software does what it is supposed to do so reliably that users stop thinking about it entirely. The difference lies in the engineering decisions that happen before, during and after feature development — the edge case handling, the performance work, the error design, the monitoring, and the cultural commitment to preventing failure rather than just responding to it.

Share

The post The Best Software Is Invisible: What Great Engineering Actually Looks Like 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.