Code10x

Embedded server (Tomcat) deta hai — har microservice, ek independent standalone JAR ki tarah run ho sakti hai, koi separate application server install kiye bina.

Microservices-specific tools — service discovery, config management, aur resilience jaise cross-cutting concerns ko handle karta hai.

Module boundaries ko clearly identify karna, phir gradually ek module ko ek time par extract karna, apni OWN database ke saath.

Ye naam hi hai jisse service discovery (Eureka) aur load balancing tools, ek service ko identify karte hain.

start.spring.io se ek naya microservice project generate karne ka easiest way — dependencies choose karke ek working skeleton milta hai.

Curated dependency bundles — manually har individual library version manage karne ki zaroorat khatam ho jaati hai.

Controller (REST endpoints), service (business logic), repository (data access), aur model/dto.

Taaki saari Spring Cloud libraries ki versions compatible rahein — dependency management ke through.

Ek umbrella project hai — service discovery (Eureka), API gateway, config management, aur resilience (Resilience4j) jaise multiple sub-projects ko combine karta hai.

Har release train (jaise "2023.0.x") ek specific Spring Boot version ke saath compatible hoti hai — semantic versioning se alag pattern hai.

Eureka, actively maintained hai. Hystrix aur Ribbon, maintenance mode mein hain.

Resilience4j — lightweight hai aur functional programming ke saath better integrate hota hai.

Kubernetes khud native service discovery (DNS-based) aur ConfigMaps (config management) deta hai.

Config ko environment mein store karna (code mein nahi), stateless processes, aur logs ko event streams ki tarah treat karna.

Session state ko application mein store karne ke bajaye, external store (Redis, database) mein rakhna chahiye — taaki kisi bhi instance par request route ho sake.

Ek central registry hai — @EnableEurekaServer annotation se, saari microservices apne instances ko register karti hain.

Multiple instances ke saath run kiya jaata hai — har instance, dusre instances ke saath registry data replicate (sync) karta hai.

Har few seconds mein ek heartbeat bhejta hai — agar ek instance se heartbeats rukh jaate hain, Eureka use eventually registry se hata deta hai.

Consul mein KEY-VALUE store aur health checking built-in hai — language-agnostic hai, polyglot microservices ke liye ideal.

Self-registration mein, service khud ko register karti hai (Eureka default). Third-party mein, ek external component (Kubernetes) ye kaam karta hai.

localhost:8761 — saari registered services aur unke healthy/unhealthy status ko visually dikhata hai.

Eureka Server ko khud ko dusre Eureka Server mein register karne se rokta hai — standalone Eureka Server setup ke liye use hota hai.

Ek reactive (non-blocking) API gateway hai — routes, predicates, aur filters ke saath configure kiya jaata hai.

Gateway ko batata hai ki target URI ek Eureka-registered service naam hai — automatically load balancing karta hai.

Ki ek request ek particular route ko match karti hai ya nahi — Path predicate most common hai.

Requests ko downstream service tak pahunchne se pehle ya response ko client tak pahunchne se pehle modify karte hain.

Zuul, blocking (servlet-based) hai. Spring Cloud Gateway, reactive (non-blocking, Netty-based) hai — high-concurrency mein zyaada efficient.

Specific routes, generic routes se pehle define kiye jaane chahiye — warna generic route pehle match ho jaayegi.

Gateway level par — har downstream service mein duplicate auth logic likhne ki zaroorat khatam ho jaati hai.

Ek declarative HTTP client hai — ek Java interface define ki jaati hai annotations ke saath, aur Feign automatically ek implementation generate kar deta hai.

Service naam se (URL ki jagah) ek dusri service ko call kiya ja sakta hai — load balancing automatically handle hoti hai.

RestTemplate, blocking client hai — Spring ne ise maintenance mode mein daal diya hai. WebClient, reactive non-blocking client hai — modern recommended choice.

Ek RestTemplate/WebClient bean ko "load-balancing-aware" banata hai — service naam se calls ki ja sakti hain, actual IP:PORT ki jagah.

Use-case par — Kafka high-throughput event streaming ke liye behtar hai, RabbitMQ complex routing aur traditional task queues ke liye behtar hai.

Ek method ko ek topic ka consumer banata hai.

RabbitTemplate, messages send karne ke liye use hota hai. @RabbitListener, messages receive karne ke liye.

Ek central filing cabinet — @EnableConfigServer se, saari services ki configuration ek central jagah se serve hoti hai, typically ek Git repository se.

Version control ke benefits deta hai — configuration changes ki history track ki ja sakti hai, aur rollback easy ho jaata hai.

Ek microservice ko Config Server se apni configuration fetch karne ke liye configure karta hai.

Ek bean ko "refreshable" banata hai — /actuator/refresh endpoint call karne par, bean ki properties bina application restart ke update ho jaati hain.

Saari instances ke across ek hi time par refresh trigger kar sakta hai — manually har instance ko call karne ki zaroorat khatam.

Plain-text mein store karna avoid karna chahiye — Vault ya Config Server ki encryption capabilities use karni chahiye.

Environment-specific configuration manage karne deते hain (dev, staging, prod) — spring.profiles.active se decide hota hai kaun sa profile active hai.

Agar failure rate ek configured threshold se zyaada ho jaata hai, circuit open ho jaata hai — fallbackMethod ek alternative response deta hai.

Lightweight hai aur functional programming ke saath better integrate hota hai — Hystrix ka modern replacement hai.

Ek method ko automatically retry karta hai agar woh ek exception throw karta hai — maxAttempts aur waitDuration configure kiye ja sakte hain.

@CircuitBreaker ko outer (upar) rakhna chahiye taaki retries circuit breaker ke andar kaam karein.

Ek method ke concurrent executions ko limit karta hai — Semaphore aur ThreadPool, do implementations hain.

ThreadPool, true isolation deta hai (separate threads). Semaphore, lightweight hai lekin same thread pool share karta hai.

Ek method ke execution rate ko limit karta hai — downstream services aur third-party APIs ko overload hone se bachata hai.

Har service, apna alag spring.datasource configuration rakhti hai — cross-service JOINS, database level par possible nahi hain.

Sirf ek single database ke andar — multiple microservices ke across (alag databases ke saath) atomic transaction maintain nahi kar sakta.

Event listeners (@KafkaListener) se — har service events ko listen karke apna kaam karti hai aur apna event publish karti hai.

Event sourcing aur saga orchestration ka built-in support — orchestration-based saga implement karne ke liye popular library hai.

Do alag sets of entities/repositories banaye jaate hain — ek write-optimized (normalized), ek read-optimized (denormalized).

"Dual write" problem — ek event ko database change ke saath SAME local transaction mein ek outbox table mein write kiya jaata hai.

Ek database write aur ek message publish, do separate operations hain — agar ek fail hoti hai aur dusri succeed, system inconsistent state mein chala jaata hai.

/actuator/health, /actuator/metrics, aur many aur endpoints automatically available ho jaate hain.

HealthIndicator interface implement karke — jaise ek external dependency ki health verify karne ke liye.

Spring Cloud Sleuth ka modern replacement — har request ko ek trace ID aur span ID assign karta hai.

Visualization tools hain jahan traces view kiye ja sakte hain — ek request ka poora flow aur har service mein laga time dekha ja sakta hai.

Docker image layers — dependencies (jo rarely change hoti hain) aur application code (jo frequently change hota hai) ko alag layers mein rakhta hai.

/actuator/health/liveness — Spring Boot 2.3+ mein separate liveness/readiness endpoints available hain.

Environment-specific values ko Spring Boot application ke andar INJECT karne ke liye — code mein hardcode kiye bina.

Monolith aur nayi extracted service ko ek saath coexist karne deta hai, transition period ke dauran.

Spring Cloud LoadBalancer — client-side load balancing ke liye modern replacement.

Agar ek saath bahut saare instances "down" dikhte hain, unhe immediately registry se hatata nahi hai — network glitch se "mass eviction" avoid karta hai.

Traffic ko multiple versions ke beech percentage-based split karta hai — canary deployments ke liye gateway-level par.

Custom error handling — HTTP error status codes ko custom exceptions mein convert karne ke liye.

Ek application start hi nahi hogi agar Config Server se connect nahi ho paati — missing config ke saath silently run hone se rokta hai.

Jab rate limit exceed hoti hai — ek fallback method ek 429 (Too Many Requests) response return kar sakta hai.

Read model ko har write-side event par update kiya jaata hai (@EventListener/@KafkaListener se), taaki read queries extremely fast rahein.

Kitna percentage of requests trace kiye jaate hain — production mein full (100%) tracing overhead add kar sakta hai, isliye lower sampling rate use hoti hai.

Nayi extracted service aur purani monolith code, dono ko parallel mein chalate hue results compare karna, confidence lene ke liye.

Processes fast start aur gracefully stop ho sakein — SIGTERM handling se in-flight requests ko complete hone ka time milta hai.

Consul, "agent" model use karta hai — har node par ek local agent run hota hai (server ya client mode mein).

Redis ke saath, gateway level par har user/API key ke liye rate limiting implement karta hai.

Un messages ke liye hai jo process nahi ho paaye (max retries exceed karne ke baad) — manual investigation ke liye alag queue mein rakha jaata hai.

Multiple config sources (command-line, environment variables, application.yml, Config Server) ek specific order mein merge hote hain — samajhna zaroori hai ki kaun sa source "win" kar raha hai.

Rate limiter, time-based hai (jaise "10 calls per second"). Bulkhead, concurrency-based hai (jaise "5 concurrent calls max").

Har microservice ke integration tests apna ephemeral database container spin up kar sakte hain — real database ke saath test karna possible hota hai.