One city team wants Python for a GIS microservice while another prefers Java for billing, as long as the published HTTP contract stays stable. What makes that polyglot choice viable?
Select an answer to reveal the explanation.
Short Explanation
Services talk through a doorway (the contract), not by sharing the same living room. Once the doorway stays the same shape, each room can be furnished in a different language.
Full Explanation
Polyglot microservices work when each service is an independent process speaking a stable published API. Process isolation plus a versioned HTTP contract lets the GIS team ship Python and the billing team ship Java without sharing a language runtime, as long as request and response shapes stay compatible. The seam is the contract, not the living room of a shared process—so municipal teams can pick the best tool per domain without a citywide language mandate.
A shared in-process framework that forces one language runtime collapses that seam and removes the freedom the scenario asks for. Compiling both services into a single binary before each release re-monoliths the deployable and couples release cadence and toolchain. Requiring every team to adopt the Functions FDK language list first confuses optional Functions packaging constraints with the general microservices boundary; FDK support is not what makes polyglot services viable across ordinary HTTP services.
Exam caveat: polyglot is a consequence of isolation, not a requirement to use every language—extra runtimes still mean extra operational surface. Operational check: contract-test the published OpenAPI or equivalent between GIS and billing in CI so a language upgrade on one side cannot silently break the other without a failing gate.