Scaling microservices combines several techniques, horizontal scaling, load balancing, database scaling, service mesh, caching, and asynchronous processing, and application.yaml/properties alone is not enough; the cloud environment needs its own configuration too.
Key Points: • Horizontal scaling adds more instances, typically managed by Kubernetes, while a load balancer or Ingress distributes traffic across them. • Database scaling uses sharding or read replicas so the database doesn't become the bottleneck once compute scales out. • A service mesh like Istio manages inter-service traffic, retries, and observability once the number of instances grows. • Caching with Redis and asynchronous processing with a message queue like RabbitMQ reduce load on synchronous request paths. • Beyond application.yaml/properties, you also need environment variables for secrets, service discovery configuration, a centralized config service like Spring Cloud Config, monitoring with Prometheus, and cloud-defined auto-scaling policies and thresholds.
Example: A Spring Boot service might define its default settings in application.yml, but the actual number of running pods, the CPU threshold that triggers a new pod, and the secrets used to connect to the database are configured in Kubernetes manifests and the cloud provider's console, not in the properties file.
Interview Tip: A concise interview answer is:
"application.yaml or application.properties only configures the app itself; scaling also needs infrastructure-level configuration like Kubernetes replica counts and autoscaling policies, service discovery, externalized secrets, a centralized config server, and monitoring. In practice I combine horizontal scaling, load balancing, database scaling, caching, and async messaging, all driven by metrics-based auto-scaling in the cloud environment."