Microservices

1. 1.What are microservices, and how do they differ from a monolithic architecture?easy

   Microservices is an architectural style where an application is built as a suite of small services. Each one runs in its own process, owns its own data, and talks to the others over lightweight mechanisms such as HTTP APIs or messaging. Each service is built around a business capability and can be deployed independently by the team that owns it.

   A monolith is a single deployable unit: all modules share one codebase, one process and usually one database, and they call each other in-process.

   The key differences:

   • Deployment: one artifact for the monolith versus independent deploys per service.
   • Scaling: scale the whole app versus scale only the busy services.
   • Data: one shared database versus a database per service.
   • Failure: in-process calls versus network calls that can fail partially.

   Microservices trade simplicity for independent deployability and team autonomy, so they pay off mainly for larger systems and organizations.

   What interviewers listen for

   • Small services built around business capabilities
   • Independently deployable; each service owns its data
   • Communicate over the network: HTTP, gRPC or messaging
   • Monolith: one deployable, one process, shared database
   • Trades simplicity for autonomy and independent scaling

   Likely follow-up: How small should a microservice be?

   answer it out loud →
2. 2.What are the main advantages and disadvantages of a microservices architecture?easy

   Advantages

   • Independent deployment: a team ships its service without coordinating a big release.
   • Team autonomy: small teams own a service end to end, which helps the organization scale.
   • Independent scaling: scale checkout without scaling the whole application.
   • Fault isolation: if you design for it, a failing non-critical service degrades one feature instead of taking everything down.
   • Technology flexibility: each service can pick the stack that suits it.

   Disadvantages

   • Distributed-systems complexity: network latency, partial failures, and timeouts and retries everywhere.
   • Data consistency: no ACID transactions across services, so you need sagas and eventual consistency.
   • Operational overhead: CI/CD, monitoring, tracing and a container platform for many deployables.
   • Harder testing and debugging: one request crosses many services and log streams.

   It's a trade: you buy autonomy and scalability, and you pay for them in operational and design complexity.

   What interviewers listen for

   • Independent deployment and team autonomy
   • Scale and isolate failures per service
   • Cost: network failures, latency, distributed debugging
   • No cross-service ACID transactions; eventual consistency
   • Needs mature CI/CD, monitoring and automation

   answer it out loud →
3. 3.When should you NOT use microservices?easy

   I'd avoid them, or at least start with a well-structured monolith, when:

   • The team is small. If one or two teams own everything, microservices add coordination and operational cost without the autonomy benefit.
   • The domain is new or unclear. Service boundaries are expensive to move later, and wrong ones give you a distributed monolith. It's easier to discover boundaries inside a monolith first.
   • Operational maturity is missing. Without automated CI/CD, containers, centralized logging, metrics and tracing, dozens of services become unmanageable.
   • Most operations need strong consistency across what would become several services, which forces sagas everywhere.
   • Scale and release cadence don't require it. A monolith scales horizontally well for many products.

   Martin Fowler calls this the "microservice premium": the extra cost is only worth paying once the system is complex enough that a monolith is hard to manage. A common path is monolith first, then extract services where there's a clear need.

   What interviewers listen for

   • Small team or early-stage product
   • Unclear domain means boundaries will likely be wrong
   • Missing CI/CD, observability and automation
   • Microservice premium: the cost only pays off with complexity
   • Prefer monolith first; extract services when needed

   Likely follow-up: What signals tell you it is time to split a monolith?

   answer it out loud →
4. 4.How do you decide the boundaries of a microservice when decomposing a system?mid

   I decompose around the business, not around technical layers.

   • By business capability: what the business does, such as order management, payments, inventory or shipping. Capabilities are stable, so services built on them are too.
   • By DDD subdomain and bounded context: a bounded context is a boundary inside which one model and its language stay consistent. "Product" in the catalog context is a different model from "product" in shipping, so they belong in different services with their own models.

   Then I sanity-check each candidate:

   • High cohesion: things that change together live together.
   • Low coupling: it can do most of its work without synchronous calls to others.
   • Ownership: one team can own it end to end.
   • Data: it owns its data, and no aggregate (a consistency boundary) spans two services.

   Anti-patterns: one service per table (entity services), splitting by layer, and services so fine-grained that every request fans out into chatty calls.

   What interviewers listen for

   • Decompose by business capability or DDD subdomain
   • Bounded context: one consistent model and language
   • High cohesion, low coupling, single-team ownership
   • Aggregates must not span services
   • Avoid entity services and layer-based splits

   Likely follow-up: What is an aggregate in DDD, and why does it matter for service boundaries?

   answer it out loud →
5. 5.What is the database-per-service pattern, and why is sharing one database between services discouraged?easy

   Each service owns its data, and other services reach it only through that service's API or events, never by querying its tables directly. Ownership can be a private set of tables, a private schema, or a separate database server; what matters is that nobody else touches it.

   Why:

   • Loose coupling: a service can change its schema without breaking others.
   • Independent deployment and scaling: no shared migrations to coordinate.
   • Polyglot persistence: one service can use PostgreSQL, another a document store or a search index.

   A shared database quietly couples services: a renamed column breaks three teams, and one service's heavy query slows everyone down.

   The costs are real:

   • Queries that join data across services need API composition or a CQRS read model.
   • Updates that span services need sagas instead of ACID transactions.
   • Some data gets duplicated and is only eventually consistent.

   What interviewers listen for

   • Service data is private; access only via API or events
   • Private tables, schema or server all qualify
   • Enables independent schema changes and polyglot persistence
   • Cross-service queries: API composition or CQRS
   • Cross-service updates: sagas, not ACID transactions

   Likely follow-up: How would you build a report that needs data from five services?

   answer it out loud →
6. 6.What is an API gateway, and what responsibilities does it usually take on?easy

   An API gateway is the single entry point that external clients call; it routes each request to the right internal service, so clients don't need to know how many services exist or where they run.

   It usually handles cross-cutting concerns:

   • Routing and load balancing to backend services.
   • Authentication: validating tokens at the edge before traffic gets in.
   • Rate limiting and quotas per client or API key.
   • TLS termination, CORS and request size limits.
   • Aggregation: combining several service calls into one response to cut client round trips.
   • Protocol translation, such as REST outside and gRPC inside.
   • Observability: access logs, metrics, and starting the distributed trace.

   The risks: it sits on every request path, so it must be highly available and fast, and it shouldn't grow into a shared monolith full of business logic that every team has to change. Keep it to routing and cross-cutting concerns; business rules belong in the services.

   What interviewers listen for

   • Single entry point that routes to internal services
   • Auth, rate limiting and TLS termination at the edge
   • Can aggregate calls and translate protocols
   • Must be highly available; it is on every path
   • Keep business logic out of the gateway

   Likely follow-up: How does an API gateway differ from a service mesh? · What is the Backend for Frontend pattern?

   answer it out loud →
7. 7.Compare synchronous and asynchronous communication between microservices. When would you use each?easy

   Synchronous (REST or gRPC request/response): the caller waits for the answer.

   • Simple to reason about, with an immediate result, which suits queries and user-facing reads.
   • But it creates temporal coupling: both services must be up at the same moment. Availability multiplies along a call chain, so three services at 99.9% each give roughly 99.7% for the chain, and latencies add up.

   Asynchronous (messages or events through a broker such as Kafka or RabbitMQ): the sender publishes and moves on.

   • Decouples services in time: a consumer can be down and catch up later, and the broker absorbs load spikes.
   • New consumers can subscribe without changing the producer.
   • But you get eventual consistency, a broker to operate, duplicate or out-of-order messages to handle, and flows that are harder to trace.

   Rule of thumb: synchronous for queries where the caller needs the data now; asynchronous for state changes that can finish in the background and for telling other services that something happened.

   What interviewers listen for

   • Sync: simple and immediate, but temporally coupled
   • Availability and latency compound across sync call chains
   • Async: decoupled in time; the broker buffers spikes
   • Async costs: eventual consistency, duplicates, harder tracing
   • Sync for queries; async for state changes and events

   answer it out loud →
8. 8.What is service discovery? Explain client-side versus server-side discovery.easy

   Instances come and go and change addresses as they scale or restart, so callers need a way to find a healthy one. Instances are recorded in a service registry, either by registering themselves or by the platform doing it for them, and they're removed when health checks fail.

   • Client-side discovery: the caller queries the registry and picks an instance itself with a client-side load balancer. Eureka with Spring Cloud LoadBalancer is the classic Java example. It saves a hop and allows smarter balancing, but every language and framework needs a discovery client.
   • Server-side discovery: the caller sends the request to a router or load balancer, which looks up the registry and forwards it. Clients stay simple. In Kubernetes, a Service gives a stable DNS name and virtual IP and the platform routes to ready pods, so most teams on Kubernetes don't run a separate registry.

   The trade-off is client complexity versus an extra hop through a component that must be highly available.

   # Callers use http://inventory-service instead of pod IPs
   apiVersion: v1
   kind: Service
   metadata:
     name: inventory-service
   spec:
     selector:
       app: inventory      # routes to ready pods with this label
     ports:
       - port: 80
         targetPort: 8080

   What interviewers listen for

   • Registry tracks healthy instances and their addresses
   • Client-side: caller queries the registry and load-balances
   • Server-side: a router or load balancer does the lookup
   • Kubernetes Services give DNS-based server-side discovery
   • Self-registration versus platform (third-party) registration

   answer it out loud →
9. 9.What is the circuit breaker pattern, and what are its states?easy

   A circuit breaker wraps calls to a remote dependency and stops calling it when it's clearly failing. The caller fails fast instead of tying up threads waiting on timeouts, and the struggling service gets room to recover.

   It has three states:

   • Closed: calls pass through while the breaker records successes, failures and slow calls in a sliding window.
   • Open: once the failure rate or slow-call rate crosses a threshold, calls are rejected immediately, usually going to a fallback. In Resilience4j a rejected call throws CallNotPermittedException.
   • Half-open: after a wait, a few trial calls are let through. If they succeed the breaker closes; if not, it opens again.

   Good practice: require a minimum number of calls before evaluating the rate, so two failures at startup don't trip it; use one breaker per dependency; and emit metrics and alerts on state changes. A circuit breaker complements timeouts and retries rather than replacing them.

   resilience4j:
     circuitbreaker:
       instances:
         paymentService:
           slidingWindowType: COUNT_BASED
           slidingWindowSize: 20
           minimumNumberOfCalls: 10
           failureRateThreshold: 50        # percent
           slowCallDurationThreshold: 2s
           slowCallRateThreshold: 50
           waitDurationInOpenState: 30s
           permittedNumberOfCallsInHalfOpenState: 3

   What interviewers listen for

   • Fails fast when a dependency is unhealthy
   • Closed, open and half-open states
   • Trips on failure-rate or slow-call-rate thresholds
   • Half-open lets trial calls through before closing
   • Pair with timeouts, fallbacks and monitoring

   Likely follow-up: Should the retry wrap the circuit breaker, or the other way around?

   answer it out loud →
10. 10.What is the saga pattern? Compare choreography and orchestration.mid

    A saga keeps data consistent across services without a distributed transaction. It's a sequence of local transactions: each service updates its own database and triggers the next step with a message or event. If a step fails, the saga runs compensating transactions that semantically undo the steps already done, such as releasing reserved stock or refunding a payment.

    Two ways to coordinate one:

    • Choreography: no coordinator. Each service reacts to events and publishes its own: orders emits OrderCreated, inventory reacts and emits StockReserved, and so on. It's loosely coupled and fine for a few steps, but the flow is implicit and spread across services, so it gets hard to follow, change and debug as it grows.
    • Orchestration: a saga orchestrator sends commands to each participant and reacts to their replies. The flow lives in one place, which is easier to understand, test and monitor, at the cost of a central component you must keep free of other services' business logic.

    I use choreography for short, simple flows and orchestration for longer ones with complex compensation.

    What interviewers listen for

    • Sequence of local transactions, no distributed lock
    • Compensating transactions undo completed steps on failure
    • Choreography: services react to events, no coordinator
    • Orchestration: a central coordinator sends commands
    • Sagas lack isolation and are eventually consistent

    Likely follow-up: How do you handle a compensating transaction that itself fails?

    answer it out loud →

No questions match that filter.