The choice between request-response and event-driven communication patterns is one of the most consequential architectural decisions in distributed system design. It determines how services couple to each other, how failures propagate, how the system scales under load, and how difficult it is to trace the flow of data through the system when things go wrong. Most teams treat it as a technology choice — Kafka versus REST — when it is primarily a design choice about how services should relate to each other.

Internal APIs — interfaces between services within an organization’s own systems — receive less design attention than public APIs because they lack the external consumer accountability that forces quality. The teams that consume internal APIs are colleagues, not customers. Breaking changes can be coordinated by Slack message rather than deprecation notice. Documentation is optional when the API author sits nearby.

The organizations that operate this way accumulate a specific kind of technical debt: internal integrations that are brittle, undocumented, and implicitly coupled to implementation details that were never meant to be part of the interface. The cost of this debt is the engineering time spent maintaining integrations that should be stable, debugging failures caused by undocumented behavior changes, and slowing down service evolution because teams are afraid to change APIs that other teams depend on in ways nobody has mapped.

Third-party API integrations are the debts that engineering organizations incur with optimism and repay with regret. The integration that takes two days to build and saves six months of custom development looks like an unambiguous win until the third-party API changes its pricing, introduces a breaking change, degrades in availability, or is discontinued entirely. The costs of the dependency were deferred, not eliminated. They appear later, at a time not of the integrating team’s choosing, with a magnitude that was not budgeted.

The API gateway decision — whether to build custom routing and middleware infrastructure or to adopt a commercial or open-source gateway product — is one of the more consequential infrastructure choices an API team makes, and it is frequently made at the wrong time with the wrong information.

The wrong time is too early: a team of three engineers building an API with one consumer has different infrastructure requirements than a team of thirty engineers building an API platform with hundreds of consumers. The wrong information is a product comparison done without a realistic understanding of the operational overhead that gateway products introduce regardless of their feature set.

The choice between REST, GraphQL, and gRPC is treated in most discussions as a question of technical preference when it is primarily a question of context. Each protocol was designed for a specific problem space. Each performs well in that space and poorly outside it. The comparison articles that declare one winner across all use cases are either selling something or have not operated all three at production scale.

REST’s dominance in public API design is not accidental. The constraints it imposes — statelessness, uniform interface, resource-based addressing — map naturally to HTTP’s caching infrastructure, client library ecosystems, and the mental model that most developers already carry from web development. A REST API can be consumed with curl. It can be documented with OpenAPI. It can be cached at the edge. These properties have real operational value that architectural elegance alone cannot purchase.