A court-scheduling service takes several minutes of JVM warm-up before accepting traffic and ignores termination signals, dropping in-flight bookings when instances are replaced. Which disposability improvement should the team prioritize?
Select an answer to reveal the explanation.
Short Explanation
Disposability is like a fire crew that can suit up in seconds and hand off the hose cleanly when relieved. Fast startup and graceful shutdown make scale-out and self-heal real. Long warm-ups and ignored termination signals fight the platform.
Full Explanation
Disposability for the court-scheduling service means processes start fast enough to be useful in seconds and shut down gracefully so in-flight bookings finish or new work is refused cleanly. Minutes of JVM warm-up before accepting traffic and ignoring termination signals make instances expensive to replace and cause dropped bookings whenever the platform recycles a replica. Fast startup plus signal-aware drain is what makes scale-out and rolling replace safe for a scheduling API.
Lengthening warm-up further so only one instance ever needs to start each quarter fights disposability and elasticity; you become dependent on a long-lived warm process. Crashing immediately on any signal without draining work frees CPU while abandoning in-flight bookings—the opposite of graceful shutdown. Pinning every process to a single physical host and refusing platform-initiated restarts rejects the cloud’s right to move and replace instances.
Exam caveat: disposability is both quick start and graceful stop; optimizing only one side still drops traffic or slows recovery during replace events.
Operational check: time cold start until readiness, send SIGTERM during an in-flight booking, and verify the instance drains or rejects cleanly without silently dropping the booking, then confirm a replacement becomes ready within an acceptable window.