Blog
May 18, 2026
Last updated: May 2026
Microservices are an architectural style where an application is built as a collection of small, independently deployable services that communicate over the network. Each service owns a single business capability and its own data, allowing teams to develop, deploy, and scale parts of the system independently. The pattern powers most modern web-scale software — Amazon, Netflix, Uber, Etsy, and Spotify all run on microservices.
This guide covers what microservices are, how five well-known companies use them in production, the benefits and trade-offs, how to build a microservices architecture step by step, and how the rise of AI agents and the Model Context Protocol is changing what microservice teams need to plan for in 2026 and beyond.
Quick summary
- Definition: An architectural pattern where an application is composed of small, independently deployable services, each owning a single business capability.
- How services talk: REST APIs, gRPC, or asynchronous message queues. See gRPC vs REST.
- Why it matters: Independent deployability, fault isolation, team autonomy, elastic scaling.
- Trade-off: More operational complexity — distributed systems are harder to monitor, debug, and secure than monoliths.
- What's changed: AI agents now consume microservices via the Model Context Protocol (MCP), adding new requirements around governance, identity, and data-access controls.
What are microservices?
A microservices architecture breaks a single, large application into a network of small services. Each service:
- Owns one business capability — payments, search, recommendations, inventory
- Has its own codebase and deployment pipeline
- Has its own data store (often its own database)
- Communicates with other services via well-defined APIs (typically HTTP/REST or gRPC)
- Can be scaled, deployed, and rewritten independently of the rest of the system
The opposite of microservices is the monolith: a single application with one codebase, one database, and one deployment unit. Monoliths aren't inherently bad — they're often the right starting point — but they become harder to evolve as teams and feature surface grow.
Microservices vs monolithic architecture
The clearest way to grasp microservices is to compare them directly to the monolithic pattern they typically replace.
| Dimension | Monolithic architecture | Microservices architecture |
|---|---|---|
| Codebase | Single repository, single deployment unit | Many repos (or a monorepo with clear service boundaries), each independently deployable |
| Database | One shared database | One database per service (or per logical bounded context) |
| Deployment | Whole application redeployed for any change | Each service deploys independently, often many times per day |
| Scaling | Scale the entire app — even if only one feature is hot | Scale only the services under load |
| Failure mode | One bug can take down the whole app | Failures can be isolated to a single service |
| Team structure | One large team or many teams sharing one codebase | Small teams own services end-to-end (build, run, on-call) |
| Operational complexity | Lower — one process to monitor | Higher — distributed system, network failures, observability is essential |
| Best for | Small teams, early-stage products, simple domains | Large engineering orgs, high-scale systems, multi-team product surface |
Real-world microservices examples
The clearest way to understand the pattern is to see how five well-known companies actually use it. Each migration was driven by the same underlying problem — a monolith that had outgrown its team — but the path each took looked different.
1. Amazon
Amazon was one of the earliest companies to formalise the microservices pattern. By 2001, the original Obidos monolith that powered amazon.com had become a deployment bottleneck — every code change required coordinating across hundreds of engineers, and a single bad commit could ground the whole site.
The fix was a now-famous internal mandate from Jeff Bezos: every team would expose its capabilities as a service over the network, every service would be built as if it would one day be exposed externally, and there would be no other form of inter-process communication. The result was the architecture that eventually became AWS — the same internal services Amazon built to fix its own monolith are what it now sells to the rest of the industry.
What Amazon did:
- Decomposed Obidos into hundreds of services, each owned by a "two-pizza team" (small enough to be fed by two pizzas)
- Made each team responsible for its service end-to-end — design, build, deploy, monitor, on-call
- Mandated service-level SLAs between teams; if your service was slow, downstream teams could publicly hold you accountable
- Eventually externalised the platform as Amazon Web Services
2. Netflix
Netflix's microservices migration started in 2008 after a database corruption incident took DVD shipments offline for three days. The team concluded that the monolithic infrastructure couldn't deliver the reliability and scale needed for streaming, and embarked on a multi-year migration to AWS and a microservices architecture.
By 2012, Netflix was running more than 500 microservices on AWS, handling more than a billion API calls per day. Today the number is in the thousands. Netflix open-sourced much of the supporting infrastructure — Eureka (service discovery), Hystrix (circuit breaking), Zuul (API gateway), and the Chaos Monkey resilience-testing framework — which became the de-facto reference stack for microservices in the 2010s.
What Netflix did:
- Migrated from a single Oracle database in a private data centre to a fully cloud-native microservices architecture on AWS
- Built infrastructure for service discovery, circuit breaking, and graceful degradation
- Pioneered "chaos engineering" — deliberately injecting failures in production to test resilience
- Open-sourced its tooling, accelerating microservices adoption industry-wide
3. Uber
Uber started life as a monolithic Python and Node.js application backed by a PostgreSQL database. By 2014, with operations expanding into hundreds of cities, that architecture was breaking down: a single bug could take rides offline globally, deploys took hours, and adding a new feature required understanding the whole codebase.
Uber's response was a multi-year migration to a service-oriented architecture, eventually growing to more than 2,200 microservices. The architecture introduced its own problems — the team coined the phrase "microservice sprawl" to describe what happens when service count grows faster than tooling — and Uber later published several engineering posts about consolidating chatty services and standardising on a smaller, well-defined platform layer.
What Uber did:
- Decomposed its monolith into thousands of microservices, organised around business domains (rides, payments, dispatch, marketplace)
- Built internal tooling for service discovery, distributed tracing, and on-call rotation
- Standardised on gRPC for service-to-service communication for performance and strong typing — see gRPC vs REST
- Later consolidated some of the sprawl into a smaller platform layer to reduce operational burden
4. Etsy
Etsy's path is the counterexample that proves microservices aren't always the answer. While Amazon, Netflix, and Uber were aggressively decomposing into services, Etsy famously stayed closer to a "monolith-with-services" pattern through the 2010s, focusing on continuous deployment, feature flags, and tight engineering discipline rather than service decomposition.
Etsy still runs many independent services for specific concerns — search, recommendations, payments — but kept the core e-commerce flow in a single PHP application that all engineers contribute to, deployed dozens of times a day. The lesson: microservices aren't a checkbox. The right architecture is the one that matches your team size, deployment velocity, and product complexity.
What Etsy did:
- Maintained a "majestic monolith" for the core listing and checkout flow
- Built specific independent services for search, recommendations, image processing, and payments
- Invested heavily in continuous deployment, feature flagging, and testing — making the monolith safer to change rapidly
- Demonstrated that "monolith vs microservices" is a spectrum, not a binary choice
5. Spotify
Spotify's microservices story is often discussed alongside its organisational design — the famous "squad, tribe, chapter, guild" model where small autonomous squads own services end-to-end. By 2026, Spotify operates more than 1,500 microservices across data, recommendation, playback, and ads platforms.
The technical architecture is less novel than the organisational one. Spotify's contribution to the industry is showing how to scale the people side of microservices — keeping teams small, autonomous, and aligned with service boundaries — which turns out to be at least as hard as the technical decomposition itself.
What Spotify did:
- Built a tribe-and-squad model where small (6-12 person) squads own one or more services
- Created internal platforms (Backstage, now open-source) to standardise service scaffolding and reduce per-team overhead
- Used a mix of gRPC and HTTP/REST for service communication, with Kafka for event streaming
- Open-sourced Backstage as a developer portal that other companies now use to manage their own microservices catalogues
How to build a microservices architecture
The decision to adopt microservices is usually triggered by a constraint — deploys are slow, teams are stepping on each other, scaling the whole monolith is expensive — rather than a green-field choice. Here's the rough playbook most teams follow.
- Start with a clear domain model. Before splitting code, map your business capabilities. Domain-Driven Design's "bounded context" concept is the most useful lens here — services should align with bounded contexts, not with database tables.
- Define service boundaries. A good service has high internal cohesion and low coupling to others. If two services constantly need to call each other to do anything useful, they probably should be one service.
- Choose communication patterns. Synchronous REST or gRPC for request-response; asynchronous message queues (Kafka, RabbitMQ, SQS) for events. Most architectures use both. See REST APIs: an overview of basic principles.
- Build the API gateway layer. An API gateway handles authentication, rate limiting, routing, and observability for traffic into your service mesh — so individual services don't reinvent these concerns.
- Set up observability from day one. Distributed tracing (Jaeger, OpenTelemetry), structured logging, and metrics (Prometheus, Datadog) are not optional in a microservices system. You can't debug what you can't see.
- Plan for failure. Network calls fail, services restart, latency spikes. Use timeouts, retries with backoff, circuit breakers, and bulkheads to keep partial failures from cascading. Idempotency is essential for any operation that might be retried.
- Standardise the developer experience. If every team builds its own scaffolding, observability, and CI/CD, the operational burden grows linearly with service count. Build (or adopt) an internal developer platform — Spotify's Backstage is the open-source reference.
Benefits of microservices
The reasons companies migrate from monoliths to microservices have stayed consistent for two decades:
- Independent deployability: Each service can be deployed without rebuilding or restarting the whole application. Teams ship dozens of times a day instead of weekly.
- Language and framework freedom: One service can be Java, the next Python, the next Rust. Teams pick the best tool for their problem instead of being locked into one stack.
- Fault isolation: A bug in the recommendations service doesn't take down checkout. Failures stay contained.
- Elastic scaling: Scale only the services under load. The recommendations service can run on 200 nodes while the admin tooling runs on two.
- Team autonomy: Small teams own a service end-to-end. They decide when to deploy, how to monitor, and how to evolve their part of the system without coordinating with twenty other teams.
- Better security boundaries: Each service can have its own authentication, secrets, and data-access policies. Security incidents in one service don't compromise the others. Pair this with strong API key hygiene and OAuth 2.0 for cross-service auth.
- Easier modernisation: Strangler-fig migrations let you replace pieces of a legacy system one at a time, rather than rewriting it whole.
Trade-offs and challenges
Microservices solve specific problems but introduce new ones in return. The teams that succeed go in clear-eyed about the trade-offs:
- Operational complexity: A microservices system is a distributed system. Network failures, partial outages, race conditions, and eventual consistency all become routine concerns.
- Harder debugging: A bug that crosses three services requires distributed tracing to diagnose. Without good observability, microservices become opaque.
- Network latency: Calls that used to be in-process function calls become network round trips. Inefficient service decomposition can multiply latency by 10x.
- Data consistency: Transactions that used to span tables in one database now span services and stores. Patterns like Saga, eventual consistency, and event sourcing become essential.
- Infrastructure investment: Service discovery, distributed tracing, an API gateway, CI/CD per service, secrets management — none of this is free, and it has to exist before microservices pay off.
- Organisational change: Microservices need small, autonomous teams. If your org is structured around shared codebases or central platforms, you'll need to restructure.
Microservices in the AI era
The biggest shift to microservices architecture in the last two years isn't another framework — it's who's calling the services. AI agents built on large language models now make a growing share of API calls, fetching data, invoking tools, and chaining requests across services on behalf of users.
This creates a new layer in the stack. The Model Context Protocol (MCP), introduced by Anthropic and rapidly adopted by other LLM providers, is the emerging standard for how AI models discover and call APIs at runtime. An MCP server exposes microservice endpoints as tools the model can read and invoke; an MCP client (like Claude or ChatGPT) consumes those tools.
That changes a few things for any microservices team:
- Self-describing schemas matter more. Agents read OpenAPI specs to figure out what each service does. Vague or undocumented endpoints get skipped.
- Granular auth and scopes become essential. You don't want an LLM to delete production records or access another tenant's data.
- Rate limits and observability need to handle agent traffic patterns. AI calls are bursty and often parallel — different from human-driven traffic.
- Data access needs governance, not just authentication. Which fields can an agent read? Which cells should be redacted? Which queries should be logged for audit?
The piece of infrastructure handling that data-access layer is the AI Data Gateway — a secure intermediary between enterprise data sources and AI systems. Where a traditional API gateway handles authentication, rate limiting, and routing for human-driven traffic, an AI Data Gateway adds AI-aware controls: identity passthrough, deterministic query enforcement, prompt logging, content filtering, and field-level data governance for agent traffic.
For microservices teams already running an API gateway, an AI Data Gateway sits as a complementary layer — purpose-built for the specific risks and traffic patterns of AI consumption. See What is an AI Data Gateway for the full architecture, and Zero Trust for LLMs for how the security model works in practice.
How DreamFactory fits in
DreamFactory's foundational capability is instant REST API generation: connect a database (Oracle, SQL Server, PostgreSQL, MySQL, Snowflake, Databricks, MongoDB — 40+ supported), and the platform auto-generates a fully documented, role-protected REST API in minutes, with no code written. The platform has been doing exactly this for over a decade. Authentication (Microsoft Entra ID, OAuth 2.0, OpenID Connect, SAML 2.0, LDAP, Active Directory, API keys), role-based access control (per table, endpoint, and HTTP verb), rate limiting (per user, role, or service), audit logging (every call captured with calling user, timestamp, and payload), and OpenAPI documentation are built in. Server-side scripting in PHP, Python, or Node.js handles custom business logic.
The AI Data Gateway is the newer chapter — a built-in MCP server that exposes the same auto-generated REST API to AI agents (Claude Desktop, Claude Code, ChatGPT, Cursor, Windsurf). The company's framing: "turn your database into an auditable, governed API layer for AI." The core principle is data stays put — keep your systems of record intact, generate a governed API on top, and let AI agents query through that layer rather than receiving raw data extracts. In DreamFactory's MCP tutorial, CTO Kevin McGahey demonstrates the full flow: database credentials, one MCP call, auto-generated API, read-only role, API key — and Claude Code building a working dashboard in minutes.
DreamFactory deploys via Linux installer (Ubuntu, Debian, CentOS, RHEL, Fedora), Windows (IIS or Apache), Docker, Kubernetes via official Helm chart, or NPX quick install. Air-gapped deployment is fully supported — as used by the Vermont Agency of Transportation to expose an Oracle database and a 1970s-era IBM S370 mainframe through a unified API layer.
DreamFactory's customers include ExxonMobil, Toyota, Saint-Gobain, PPG, Deloitte, Google Cloud, AkerBP, Netgear, Miller Industries, the National Institutes of Health, the Vermont Agency of Transportation, D.A. Davidson, and Pillsbury Law — spanning energy, automotive, industrial, finance, government, healthcare, and legal. G2 rates the product 4.7 with badges for "Easiest to Use," "Fastest Implementation," and "Best ROI." See the DreamFactory AI page or request a demo.
Frequently asked questions
What is a microservices architecture?
A microservices architecture is a way of building applications as a collection of small, independently deployable services, each owning a single business capability and communicating with the others over the network — usually via REST APIs, gRPC, or message queues. Each service has its own data store, its own deployment lifecycle, and can be written in a different language from the others.
What's an example of a company using microservices?
Amazon, Netflix, Uber, Etsy, and Spotify are five of the most-cited microservices examples. Amazon broke its monolith apart in the early 2000s, Netflix migrated through 2008-2012, Uber moved off its monolith starting around 2014, Etsy adopted a hybrid model, and Spotify built its squad-and-tribe organisational model around microservice ownership.
What's the difference between microservices and APIs?
An API is the interface a service exposes — the set of endpoints other software can call. Microservices describes the architectural pattern of building an application out of many small services, each typically exposing its own API. Every microservice has APIs, but not every API is part of a microservices architecture.
How do microservices communicate with each other?
Most microservices communicate via synchronous HTTP/REST or gRPC for direct request-response calls, and asynchronous message queues (Kafka, RabbitMQ, AWS SQS) for event-driven workflows. Service meshes like Istio or Linkerd handle service-to-service authentication, retries, and observability across the network.
What are the main benefits of microservices?
Independent deployability, language and framework agnosticism, improved fault isolation (one service failing doesn't take the whole app down), team autonomy (small teams can own a service end-to-end), and elastic scaling (scale only the services under load instead of the whole monolith). For data-heavy applications, microservices also make it easier to apply per-service security, compliance, and audit controls.
What are the trade-offs of microservices?
Operational complexity, network latency, distributed-system failures, harder debugging across services, the need for sophisticated monitoring and tracing, and the up-front cost of building infrastructure (CI/CD, service discovery, observability, an API gateway). Microservices also typically require organisational changes — DevOps practices, on-call rotations per service, and product teams that align with service boundaries.
How do AI agents call microservices?
AI agents built on large language models call microservices through tools exposed via the Model Context Protocol (MCP). An MCP server wraps one or more microservice endpoints with semantic descriptions; an MCP client (Claude, ChatGPT, custom agents) reads the available tools and invokes them at runtime. For data access specifically, an AI Data Gateway sits between the agent and the underlying microservices to enforce identity passthrough, deterministic queries, and field-level redaction.
What's a microservices API gateway?
A microservices API gateway is the front door to a microservices architecture. It handles cross-cutting concerns — authentication, rate limiting, request routing, response shaping, observability — so each individual microservice doesn't have to. Common examples include Kong, AWS API Gateway, Apigee, and DreamFactory.
Related blog posts
