Monolith vs Microservices: Interview Questions and Answers

Monolith vs Microservices: Interview Questions and Answers

Interviewers often ask about monolith vs microservices. Here are the common questions with concise, honest answers.

Q1: What is the difference between a monolith and microservices?

A monolith is a single codebase that handles everything. Microservices split the app into multiple services, each with its own codebase, database, and deployment. Microservices trade simplicity for independent scaling and deployment.

Q2: When would you choose a monolith?

Small team, new product, unclear requirements, need to ship fast, no dedicated DevOps. A well-structured monolith is the right starting point for most projects.

Q3: When would you choose microservices?

Large teams, parts of the app scale or deploy independently, the monolith has become unmaintainable. The cost is justified by scale and team autonomy.

Q4: How do you split a monolith into microservices?

Use the strangler fig pattern. Pick a bounded context, extract it into a service with its own database, route traffic to it, delete the old code. Repeat. Never do a big-bang rewrite.

Q5: What is the strangler fig pattern?

You incrementally replace parts of a monolith with new services. Old code is strangled (removed) as new services take over. Each step is shippable and reversible.

Q6: Should microservices share a database?

No. Each service should own its data. Sharing databases couples services and defeats the purpose. If you need data from another service, use an API or event.

Q7: How do microservices communicate?

REST (HTTP/JSON), gRPC (HTTP/2 with Protocol Buffers), or events (pub/sub with Kafka, RabbitMQ, SQS). Sync (REST, gRPC) is simpler; async (events) decouples services and handles bursts.

Q8: How do you handle data consistency across microservices?

Use the saga pattern: each service does its part and publishes an event. If a step fails, compensating events undo prior steps. You accept eventual consistency instead of ACID transactions.

Q9: What is a circuit breaker?

A pattern that stops a service from calling a failing downstream service. The breaker trips after N failures, fast-fails subsequent calls, and trips back when the downstream recovers. It prevents cascading failures.

Q10: What are the biggest challenges with microservices?

Distributed data consistency, debugging across services, network failures, operational overhead, and team coordination. The challenges are real, not theoretical.

The Takeaway

Interview answers on monolith vs microservices: monolith for small teams and new products, microservices for large teams with real scale, strangler fig for splitting, no shared databases, REST/gRPC/events for communication, saga for consistency, circuit breakers for resilience. Be honest about the costs.