10 Microservices Patterns for Pune Java Devs (2026)

The list

1. 1

   API Gateway

   Single entry point that routes incoming requests to backend services — handles cross-cutting concerns (auth, rate-limiting, request transformation, logging) so individual services don't repeat them.

   Why it matters: Asked at ~70% of Pune microservices interviews. Spring Cloud Gateway + Netflix Zuul are the JVM defaults; cloud-native shops use AWS API Gateway or Kong.

   Best for: Foundation pattern — every microservices system has one.

2. 2

   Service Discovery

   Mechanism for services to find each other by logical name (not hardcoded IPs/ports). Services register themselves on startup; consumers query the registry to locate them.

   Why it matters: Spring Cloud Netflix Eureka is the Java-default. Kubernetes-native shops use built-in DNS-based service discovery instead.

   Best for: Production microservices — hardcoded service URLs don't scale.

3. 3

   Circuit Breaker

   Prevents cascading failures by 'opening' the circuit when downstream service fails repeatedly — fails fast instead of waiting on timeouts. Closes after a wait period to test recovery.

   Why it matters: Asked at ~55% of Pune product company rounds. Resilience4j (Spring Cloud's modern default; replaces deprecated Hystrix) is the Java standard.

   Best for: Reliability patterns; SRE + senior-fresher signal.

4. 4

   Saga Pattern

   Distributed transaction management without 2PC. Long-running business process is split into local transactions, each with a compensating action if a later step fails. Two flavours: choreography (event-driven) + orchestration (central coordinator).

   Why it matters: Asked at ~35% of Pune BFSI + e-commerce microservices interviews. Walk through an order placement example: order created → payment failed → inventory rollback via compensating event.

   Best for: BFSI + e-commerce + transactional system signal.

5. 5

   Event-Driven Architecture (Kafka)

   Services communicate via events on a message broker rather than direct sync HTTP calls — producers emit events, consumers process them async. Decouples services + enables fan-out + replay.

   Why it matters: Apache Kafka is the dominant Pune event broker. Async patterns appear in ~50% of Pune product company microservices roles.

   Best for: Modern Pune product company + financial-services interviews.

6. 6

   Database per Service

   Each microservice owns its own database — no shared schema. Avoids tight coupling but introduces complexity for cross-service queries (use API composition or CQRS).

   Why it matters: Asked at ~40% of Pune rounds. The fundamental data-ownership rule of microservices — violating it (shared DB) is the #1 anti-pattern.

   Best for: Architecture-tier question; demonstrates microservices-discipline maturity.

7. 7

   CQRS (Command Query Responsibility Segregation)

   Split write model (commands) from read model (queries) — often different stores optimised for each. Pair with Event Sourcing for full event-log audit + replay-ability.

   Why it matters: Asked at ~25% of Pune product company rounds — more common at financial services + analytics-heavy systems. Senior-fresher pattern.

   Best for: Read-heavy or audit-heavy systems; differentiator at top product cos.

8. 8

   Distributed Tracing

   Correlate logs + spans across services to trace a single request across the system. OpenTelemetry is the modern standard; Spring Cloud Sleuth + Zipkin or Jaeger are JVM-friendly backends.

   Why it matters: Asked at ~45% of Pune SRE + observability-leaning interviews. Strong signal for operational maturity beyond pure-dev candidates.

   Best for: Observability-track signal; senior-fresher product-company differentiator.

9. 9

   Config Server (Externalised Configuration)

   Centralised configuration management for all services — config changes without redeploy + environment-specific values managed in one place. Spring Cloud Config Server is the Java default; backed by Git for versioning.

   Why it matters: Asked at ~40% of Pune rounds. Mention HashiCorp Vault for sensitive config (passwords, API keys) — 12-factor app discipline.

   Best for: Configuration management depth; production-readiness signal.

10. 10

    Bulkhead Pattern

    Isolate failures by partitioning resources (thread pools, connection pools) per dependency — failure in one downstream doesn't exhaust shared resources + take down the whole service. Resilience4j supports bulkhead + circuit breaker together.

    Why it matters: Asked at ~25% of Pune SRE + high-reliability interviews. Less common at services-major fresher tier but excellent senior-fresher signal.

    Best for: Reliability engineering depth; SRE-track differentiator.