When is first-request latency from Spring Boot lazy initialization acceptable for low-traffic workloads

Context

Spring Boot's spring.main.lazy-initialization=true property defers singleton bean creation until first use, reducing startup time and memory footprint for applications with infrequently accessed endpoints.

For low-traffic workloads such as cron jobs, admin endpoints, or cold-start-sensitive serverless functions, this deferral can significantly cut resource consumption during idle periods. However, this benefit comes with a tradeoff: beans are initialized on first request rather than at startup, introducing potential latency spikes and delaying failure detection for misconfigured components.

Constraints

• Latency requirements for the first request after application start or scale event
• Need to detect configuration errors during deployment validation rather than in production
• Mixed requirements where some beans (e.g., database pools, scheduled tasks) must initialize eagerly

Question

Given these constraints, what criteria should determine whether the first-request latency penalty from lazy initialization is acceptable for a specific low-traffic application, and how should teams validate this decision before production deployment?