Question 1

What are the advantages and disadvantages of using microservices?

Accepted Answer

Microservices break a monolith into small independent services. The advantages: independent deployment so you release faster, isolated failure so one broken service does not take the whole system down, and parallel development so five teams do not block each other on one pipeline. The disadvantages: added latency, because an in-process function call becomes an HTTP call. Debugging gets hard — one failing request can cascade through seven downstream services. And you need heavy upfront investment in infrastructure. Do it too early and you pay the cost without reaping the rewards.

Question 2

How does scalability compare between microservices and a monolith?

Accepted Answer

Traffic is asymmetric: one endpoint always gets most of the load. With microservices you scale only the hot service. With a monolith you scale the whole thing to serve one route, so you overspend on infrastructure. Microservices give you granular control over where the resources go.

Question 3

Is using a different tech stack per service a real advantage?

Accepted Answer

On paper, yes. In practice, no. If one service is PHP, one is Go, and one is TypeScript, you cannot hire for that team and you cannot move developers between services.

Google is huge and uses only four languages. Keep the stack uniform even across services. The constraint is not technical — it is staffing and knowledge. It is a multi-dimensional decision.

Question 4

How do you handle logging and monitoring in a microservices architecture?

Accepted Answer

In a monolith an error gives you a stack trace. In microservices the error propagates across services A, B, C, D — often owned by different teams — so you need centralized logging and distributed tracing.

Every service pushes logs to one place. Datadog is the standard tool; not cheap, but this is enterprise architecture. A trace shows the full call chain, so you localize the failing service fast. It takes real DevOps work to wire this up across staging and production, which is why microservices only make sense once the system is big.

Question 5

How would you design a backend service to make sure it is scalable?

Accepted Answer

Scale horizontally: an elastic algorithm spawns more instances as traffic grows, behind a load balancer. That only works if the service is stateless, so use REST — requests process, read the database, return, and keep nothing in memory.

Avoid in-memory sessions. Use JWT instead: any instance can verify a token from the identity provider. If you must use sessions, use sticky sessions so the load balancer pins a user to one instance. And favor functional programming — deterministic, state-free code gives the same result on any instance.

Question 6

You scaled the service — what about the database?

Accepted Answer

Scaling the service pushes the pressure onto the data store. If your work stops there, it is in vain. Managed databases like RDS give you a lot of scaling functionality out of the box.

Beyond that: sharding splits one big table across independent databases by ID — hard to implement, but it works. And for parts of the application that do not need relational data, migrate to NoSQL — a document database scales a lot better.

Question 7

How does a load balancer actually work?

Accepted Answer

A load balancer is a web server that takes requests and distributes them across downstream instances. It knows which instances exist through service discovery: healthy instances register themselves in its table. The distribution algorithm varies. Round robin goes instance by instance. Least connections sends the request to the instance with the fewest open connections — useful because some requests cost more CPU than others. You can also route on memory and CPU usage. Build it with NGINX, or use a managed one like the AWS Application Load Balancer.

Question 8

What is the API Gateway pattern and when would you use one?

Accepted Answer

An API Gateway is the gate to your castle: a reverse proxy that sits between frontend clients and your services. Without one, frontend developers call hundreds of services directly and every service reimplements authentication, HTTPS, and caching. The gateway handles those edge functions once, then forwards the request downstream. Service teams stop worrying about auth, and the frontend authenticates against one endpoint. You save implementation cost and get uniformity.

Question 9

What is the disadvantage of using an API Gateway?

Accepted Answer

Added latency: every request is now two HTTP calls — client to gateway, gateway to service. You can mitigate it because the gateway sits geographically close to the services, so the second hop is nearly instant. The real risk is the single point of failure. If the gateway goes down, the whole system is down — you are back to the monolith's worst property.

Question 10

Why can services behind the gateway talk plain HTTP instead of HTTPS?

Accepted Answer

The HTTPS handshake takes about five round trips versus three for plain HTTP, so it adds latency — more if your users are far away. It happens under the hood, but it costs time. So terminate HTTPS at the API Gateway. Inside the VPC the services are in the safe zone and physically close together, so downstream calls can run over plain HTTP and stay almost instantaneous.

Question 11

Name three things you would add to a service to make it secure.

Accepted Answer

One: HTTPS, which protects against man-in-the-middle attacks. Two: OAuth with JWT — each service receives a token and verifies it with the identity provider before proceeding. Three: a rate limiter against DDoS — cap requests per IP over a window, or throttle by adding intentional latency to a noisy IP. Two bonus layers: CORS at the gateway so only your frontends can call from a browser, and a Content-Security-Policy header to block clickjacking-style attacks.

Microservices Interview Questions: Senior and Mid-Level Answers

Real questions, senior answers