The application is more than business logic
A service can be correct in a local environment and still be difficult to operate. Production introduces startup ordering, dependency outages, configuration mistakes, network boundaries, resource limits, deployment behavior, and observability needs.
I prefer treating those concerns as part of the software design, not as cleanup work after feature development.
Liveness and readiness answer different questions
A liveness endpoint should answer whether the process is alive. Readiness should answer whether the service is currently able to do useful work. Mixing those concepts can create restart loops or route traffic to an unhealthy dependency graph.
The same principle applies to configuration and dependency management: make failure modes explicit, validate what can be validated early, and avoid hiding errors behind automatic repair behavior in production pipelines.
Operational clarity improves architecture
Designing for production forces useful questions about boundaries and ownership. Which dependency is required? Which one is optional? What can degrade gracefully? What state is safe to retry? Those questions usually improve the application model itself.
Have a system where this tradeoff matters?
Start a conversation →