A city is splitting a monolith into microservices that must stay loosely coupled as new domain events appear. Which integration approach reduces point-to-point spaghetti?

As a city splits a monolith into microservices, new domain events must not recreate point-to-point spaghetti. Amazon EventBridge routes domain events to interested consumers through rules, so producers publish once without hard-coding every consumer’s private IP or API. That event bus approach keeps coupling loose as departments add services for permits, payments, or notifications. Content-based routing lets the same “application.submitted” event fan to fraud checks, fee calculation, and citizen status updates without rewriting the producer each time a new consumer appears.

Hard-coding every service to call every other service’s private IP directly creates a fragile mesh that breaks with scaling, AZ movement, and ownership changes. A single global mutable spreadsheet as an integration bus is not reliable, secure, or automatable middleware for production civic systems. Requiring synchronous SSH between services for every state change is operationally absurd and is not an application integration pattern—SSH is remote administration, not an event fabric.

Exam caveat: EventBridge for event-driven microservice integration; SNS/SQS remain valid for simpler pub/sub or competing consumers—EventBridge shines with content-based routing, schema registry use, and AWS/SaaS event sources. Operational check: define an event schema for “license.approved,” route to two consumer services via rules, verify producers do not reference consumer IPs, and monitor failed invocations with DLQs or an archive bus.