Inter-service communication introduces several risks that don't exist in a single-process monolith, since every call now crosses a network boundary that can fail independently of the application code.
Key Points: • Network issues — latency, packet loss, or transient outages — can slow down or break requests that would have been instantaneous in-process calls in a monolith. • Coordinating many services communicating with each other increases the chance of inconsistent data if messages arrive out of order or are lost. • Every service-to-service call is a potential security weak point; a vulnerability in one service can be leveraged to attack others it communicates with. • Heavy reliance on network calls makes debugging and root-cause analysis significantly harder, since a single failure can originate several hops away from where it's observed. • Increased number of moving parts raises the chance of partial failures, where some services succeed and others fail for the same overall business operation.
Example: A transient network partition between the Order Service and Payment Service could cause an order to be marked as placed while the payment call silently times out, leaving the system in an inconsistent state unless retries, idempotency, and reconciliation logic are in place.
Interview Tip: A concise interview answer is:
"The main risks are network unreliability causing latency or lost messages, data inconsistency when services fall out of sync, a larger security attack surface since every service boundary is a potential entry point, and much harder debugging since a failure can originate several services away from where it's observed. Mitigating these requires retries, idempotency, tracing, and careful monitoring."