Service Discovery, Data Consistency & Deployment — Interview Questions

How to use this lesson

This lesson covers the "plumbing" questions. Show that you know both the Spring Cloud way (Eureka, Spring Cloud LoadBalancer) and the Kubernetes way (Services and DNS). Most new systems use the latter. For consistency, explain why distributed transactions are avoided, and what replaces them.

Q1. What is a service registry?

Short answer: A service registry is a database of available service instances and their network locations (host, port, health, metadata). Instances register on startup and deregister on shutdown. Clients, or load balancers, query the registry to find a healthy instance. Examples: Netflix Eureka, Consul, ZooKeeper, and, implicitly, Kubernetes (the API server plus the endpoints behind each Service).

Learn it in depth → Service Discovery

Q2. How does service discovery work?

Short answer:

1. A service instance starts, and registers its address with the registry. It keeps sending heartbeats.
2. A caller asks for "order-service", and gets the list of healthy instances.
3. A load balancer picks one.

There are two variants:

• Client-side discovery: the caller queries the registry and balances the load itself (Eureka + Spring Cloud LoadBalancer).
• Server-side discovery: the caller hits a stable address (a load balancer, or a Kubernetes Service DNS name such as http://order-service), and the platform routes the request.

@Bean @LoadBalanced
RestClient.Builder restClientBuilder() { return RestClient.builder(); }

// "order-service" is resolved through discovery, not DNS
restClientBuilder.build().get().uri("http://order-service/api/orders/{id}", id).retrieve().body(OrderDto.class);

Q3. What happens if the service registry fails?

Short answer: It depends on the design, but it shouldn't cause an immediate outage:

• Clients cache the registry contents. Eureka clients keep their last-known list of instances, and continue calling services, although they won't see new or removed instances until the registry recovers.
• Run the registry in a cluster. Eureka peers replicate to each other, and Consul uses a Raft cluster, so one node's failure is survived.
• Eureka favours availability. Its self-preservation mode stops evicting instances when heartbeats drop sharply, on the assumption that the network is at fault rather than the services.

Key points to cover:

• The real risk is stale data: calls sent to instances that have since died. Timeouts, retries and circuit breakers on the client side cover that gap.

Q4. How do services keep their registration up to date?

Short answer: They register on startup, send periodic heartbeats (Eureka's default is every 30 seconds), and deregister on graceful shutdown. The registry evicts instances whose heartbeats stop, after a lease timeout. Clients refresh their cached registry periodically. Health checks, such as the Actuator health endpoint, can also mark an instance as down.

Key points to cover:

• On Kubernetes, readiness probes play this role. A pod is added to a Service's endpoints only when it's ready, and removed when it fails, or when it's terminating.

Q5. How do you handle data consistency in microservices?

Short answer: Each service owns its data, so there's no single database transaction across services. Consistency is achieved with:

• Sagas: a chain of local transactions, each with a compensating action.
• Domain events, published reliably with the transactional outbox pattern.
• Idempotent consumers.
• Accepting eventual consistency where the business can tolerate it.

Key points to cover:

• Keep data that must be strongly consistent inside one service (for example, stock reservations within the inventory service).

Learn it in depth → Outbox Pattern

Q6. What is eventual consistency?

Short answer: A consistency model in which, after an update, the different copies or services may disagree temporarily. If no new updates arrive, they all converge to the same state. For example, after an order is placed, the order service knows immediately, while the analytics dashboard and loyalty points catch up a few seconds later, through events.

Key points to cover:

• Design for the gap. Show a "processing" state in the UI, make the operations idempotent, and handle out-of-order events (with version numbers or timestamps).

Learn it in depth → Eventual Consistency Design

Q7. How would you implement a transaction that spans multiple services?

Short answer: With the Saga pattern. The business transaction is split into a sequence of local transactions, one per service. If a step fails, the steps that already completed are undone by compensating transactions, business-level reversals such as "refund payment" or "release stock".

• Choreography: services react to each other's events. It's simple for short flows.
• Orchestration: a central coordinator (a state machine, or a workflow engine such as Temporal or Camunda) tells each service what to do. It's clearer for long flows.

PlaceOrder:  Order(PENDING) → Payment.charge → Inventory.reserve → Order(CONFIRMED)
On failure at Inventory.reserve:  Payment.refund → Order(CANCELLED)

Common trap: proposing two-phase commit (XA) across microservices. It couples services' availability, holds locks across the network, and most modern datastores and brokers don't support it well.

Learn it in depth → Saga Pattern

Q8. What are the trade-offs between eventual and strong consistency?

Short answer:

Key points to cover:

• This is the practical face of the CAP/PACELC trade-off. Choose per use case, not per system.

Learn it in depth → CAP Theorem

Q9. What strategies are used to deploy microservices?

Short answer: Each service is packaged as a container image, deployed through a CI/CD pipeline, and run on an orchestrator (Kubernetes, or ECS). The release strategies are:

• Rolling updates, the Kubernetes default: replace pods gradually.
• Blue-green.
• Canary.
• Feature flags, to separate deploying code from releasing features.

Learn it in depth → Deployment Strategies

Q10. What is blue-green deployment?

Short answer: You run two identical production environments. Blue serves live traffic while green gets the new version. After green passes its checks, you switch all traffic to green (at the load balancer or router). Rollback is just switching back.

Key points to cover:

• Pros: near-zero downtime, instant rollback, and the new version can be tested in a production-like environment.
• Cons: double the infrastructure during the switch, and database migrations must be backward-compatible, because both versions share the database (the expand/contract pattern).

Q11. How does a canary release differ from blue-green?

Short answer: A canary sends a small percentage of real traffic (say 5%) to the new version, watches the error rate and latency, then increases the share step by step. A problem affects only a few users. Blue-green switches all traffic at once.

Key points to cover:

• Canaries need good metrics and automated analysis (Argo Rollouts, Flagger, Spinnaker) to decide whether to promote or roll back.

Q12. What tools would you use to automate microservices deployment?

Short answer:

• Docker (or buildpacks and Jib) to build images.
• CI pipelines: GitHub Actions, GitLab CI, Jenkins.
• Kubernetes, with Helm or Kustomize for manifests.
• GitOps with Argo CD or Flux.
• Terraform for the infrastructure.
• Argo Rollouts or Flagger for progressive delivery.

Learn it in depth → CI/CD Pipeline Design

Follow-up questions this topic invites — and their answers

Q: Do you still need Eureka on Kubernetes? A: Usually not. Kubernetes Services, DNS and readiness probes already provide discovery and load balancing. Eureka is mostly used in VM-based or hybrid deployments.

Q: What is the transactional outbox pattern? A: Write the business change and an "event to publish" row in the same local transaction. A separate relay (a poller, or CDC with Debezium) publishes the outbox rows to the broker. That avoids the dual-write problem, where the database commits but the event is lost, or the reverse.

Q: How do you roll back a canary that uses a new database column? A: Make schema changes expand-first. Add the new nullable column, and deploy code that writes both the old and new columns. Only after the rollout is fully complete do you remove the old column in a later release. Then the old version keeps working throughout.

Q: Choreography or orchestration for sagas? A: Choreography suits simple flows with a few steps, because there's no central component. Orchestration is easier to understand, monitor and change when there are many steps or complex compensation rules.