Microservices Quiz — 7 Free Questions

Question 1

What does "Cross-Origin Resource Sharing" (CORS) configuration on an API Gateway control?

Question 2

What does an "error budget", derived from a service's SLO, help a team decide?

Question 3

What is the role of a message broker, such as RabbitMQ or Kafka, in a microservices architecture?

Question 4

What is a common approach for handling authentication when a request passes through several microservices?

Question 5

What tradeoff does adopting gRPC for internal microservices communication typically introduce, compared to REST?

Question 6

What is a "shared-nothing" architecture principle, as commonly applied to individual microservice instances?

Question 7

What problem does the Saga pattern primarily address in a microservices architecture?

📚 All Quizzes

Browse every category and see the full list of quizzes on BriskQuiz

→

About Microservices

Microservices aren't a programming language or a specific tool, they're a way of designing software. Instead of building one large application, often called a monolith, you break the system into many small, independent services that each do one job well and talk to each other over the network, usually through simple APIs.

The approach got its biggest spotlight from companies like Netflix and Amazon, who needed to scale both their infrastructure and their engineering organizations independently rather than having every code change ripple through one giant, tightly coupled codebase. Amazon famously enforced this with its "two-pizza team" rule: no team should be larger than what two pizzas could feed, and each small team owned one service end to end, from writing the code to running it in production.

There's a well-known piece of advice in software architecture, often summarized as "monolith first" and credited to the writer Martin Fowler, which suggests most teams are better off starting with a simpler, unified codebase and only splitting into microservices once they genuinely understand where their system's natural boundaries lie. Splitting too early, before you know where those seams should be, tends to create more problems than it solves.

That's because microservices come with real, well-documented tradeoffs. What used to be a simple function call inside one program becomes a network request that can fail, arrive late, or arrive out of order, which introduces entire categories of complexity, like eventual consistency and distributed transactions, that a monolith never has to think about at all.

Modern microservice systems usually lean on supporting infrastructure to manage that complexity, an API gateway to route incoming requests to the right service, and increasingly a service mesh like Istio to handle the network traffic, security, and observability between services without every team having to solve those problems themselves from scratch.

There's also an interesting organizational pattern behind all of this, often referred to as Conway's Law, which observes that the systems a company builds tend to mirror the communication structure of the teams that built them. Microservices architecture and small, autonomous engineering teams tend to reinforce each other almost by design.

Observability became its own entire discipline as microservices spread, since debugging a problem that spans a dozen independent services is nothing like debugging a single monolithic program. Tools for distributed tracing, centralized logging, and real-time monitoring became essential rather than optional once companies committed seriously to the microservices approach, and an entire industry of infrastructure tooling grew up specifically to make that complexity manageable.

Beyond Netflix and Amazon, companies like Uber and Spotify have also become well-known case studies in microservices adoption, each running many hundreds of independent services in production, though both have also publicly discussed the operational overhead that comes with running architecture at that scale, a useful reminder that microservices solve organizational and scaling problems more than they solve raw performance problems on their own.

The term "microservices" itself only really entered common use around 2011 and 2012, popularized through conference talks and blog posts from engineers already practicing the pattern, even though the underlying ideas, breaking large systems into smaller, independently deployable pieces, had existed in various forms in software architecture circles for years before anyone settled on that particular name for it.