Careeroza

Why Centralized Configuration

The Problem

ShopEase has 4 services, each with dev, test and prod settings, and each running several instances. If the Razorpay timeout or the "max items per order" value lives inside each jar, a change means rebuild, redeploy and restart. Settings also drift: one copy of order-service ends up with an old value.

Spring Cloud Config Server serves configuration over HTTP from one place (usually a Git repo). Services fetch their settings at startup.

config-repo (Git)                         Config Server :8888
  ├── application.yml        (all services)        |
  ├── order-service.yml                            |  GET /order-service/prod
  ├── order-service-prod.yml   ---- clone ---->    |
  ├── product-service.yml                          v
  └── payment-service-prod.yml           order-service (profile prod)
                                         product-service, payment-service ...

Benefits

BenefitWhat it means
One source of truthAll settings in one repo, reviewed through pull requests
History and rollbackGit log shows who changed what; git revert undoes a bad change
Per environmentorder-service-dev.yml, order-service-prod.yml
Change without rebuildEdit the repo and refresh; no new jar
Shared defaultsapplication.yml in the repo applies to every service

Note: On Kubernetes, many teams use ConfigMaps and Secrets instead (advance level). The idea is the same: config lives outside the jar (the 12-factor rule from the basic level).