If the notice service fails, city payments should keep working, so teams avoid hard synchronous coupling everywhere. Which design goal are they pursuing?
Select an answer to reveal the explanation.
Short Explanation
Loose coupling is seatbelts between departments—when notices stall, payments can still take the money. Hard synchronous chains turn one hiccup into a citywide outage. Keep the blast radius small and citizens keep moving.
Full Explanation
Loose coupling designs services so they communicate through stable interfaces and resilient patterns—queues, events, timeouts, and bulkheads—limiting how far a failure propagates. When city payments must keep working even if the notice service fails, teams are explicitly pursuing loose coupling instead of hard synchronous chains that force every domain to fail together. Host affinity that forces every service onto the same hypervisor as the payments VM increases correlated failure risk rather than shrinking blast radius. Tight coupling with shared in-memory state so all services fail or succeed together is the opposite design goal. Mandatory synchronous RPC for every call so timeouts always cascade recreates fragile monolith-like outages across process boundaries and departments. Exam caveat: CompTIA Cloud+ resilience items often contrast loose versus tight coupling; independent deployability alone is insufficient if runtime calls still form a brittle mesh. Operational check: move non-critical notice work off the payment request path via asynchronous messaging, add timeouts and circuit breakers on remaining synchronous calls, chaos-test a notice outage during a change window, and verify payment success rates and citizen checkout completion remain within SLA while notices degrade or queue.