Microservices Architecture

Microservices are an organizational and technical pattern. The key insight: microservices enable large teams to work independently. If you don't have the team size and operational maturity, the costs outweigh the benefits. Learn the patterns, but learn when NOT to apply them. Monolith vs Microservices: When to Split The microservices vs monolith debate is one of the most cargo-culted decisions in software architecture. Teams split their systems into microservices because Netflix and Amazon did it — without understanding the costs or whether they face the same problems. This session gives you the framework to make that decision rationally. What is a Monolith? A monolith is a single deployable unit where all features are bundled together. One codebase, one build, one deployment. This is not inherently bad. Every successful system starts as a monolith. Amazon, Netflix, Shopify — all started as monoliths. What are Microservices? Microservices decompose an application into small, independent services that communicate over a network. Each service owns its data, can be deployed independently, and is responsible for a specific business capability. The Real Costs of Microservices Before listing benefits, internalize the costs — these are often skipped in blog posts: Network latency: Every inter-service call adds 1-10ms. Chains of calls (A→B→C→D) compound this. Distributed systems complexity: CAP theorem, eventual consistency, network partitions — problems that don't exist in a monolith become your daily reality. Operational overhead: Each service needs its own CI/CD pipeline, monitoring, logging, alerting, and on-call rotation. Testing complexity: Integration tests must spin up multiple services. End-to-end tests are slow and flaky. Data consistency: No ACID transactions across services. Every multi-service workflow needs saga patterns. When Microservices Make Sense Team scale: Conway's Law states that "organizations produce systems that mirror their communication structures." A 5-person team deploying a monolith ships fast. A 500-person engineering organization can't coordinate changes to a single codebase — microservices let teams own their services independently. Independent scaling: A ride-sharing app's matching engine needs 100x the compute of its invoicing service. In a monolith, you scale everything together. In microservices, you scale only what needs it. Independent deployment velocity: If the payments team needs to deploy 10 times a day but the user profile team deploys once a week, coupling them in a monolith creates friction. Independent services allow independent release cycles. Technology diversity: Some problems demand specific tools. Your ML recommendation engine runs Python. Your high-performance trading system runs C++. Your web API runs Go. Microservices allow each to use the right tool. Netflix: The Migration Story Netflix's monolith ("the blob") ran on two data centers. In 2008, a database corruption incident took Netflix down for 3 days. This forced a rethink. Between 2009 and 2012, Netflix migrated to AWS and decomposed into hundreds of microservices. Today Netflix runs 700microservices. Their teams — 2-pizza size (6-8 people) — own services end-to-end. A recommendation change ships without touching the billing code.