Avoid sync HTTP chaining

A synchronous call is the software version of waiting on hold: one service cannot finish until the next one answers. Martin Fowler has warned that splitting systems into many services adds “significant complexity,” including remote-call failures that do not exist inside a single codebase. (martinfowler.com) That is the core complaint behind recent engineering threads arguing against long Hypertext Transfer Protocol call chains between microservices. Fowler’s microservices guide says teams should avoid a “synchronous call chain” at startup because service availability then depends on every downstream hop being up. (martinfowler.com) Cloud vendors make the same distinction in plainer terms: direct request-response calls are simple, but they tightly couple services in time. Amazon Web Services says asynchronous messaging lets one service hand off work to a queue or event bus so another service can process it later. (aws.amazon.com) That design changes the failure mode. Microsoft’s.NET microservices guidance says asynchronous communication improves autonomy and resilience, but it also introduces eventual consistency, meaning different services can briefly show different data until messages are processed. (learn.microsoft.com) A common workaround is replication instead of live dependency: copy the data each service needs, then update it with events. Fowler’s microservices article describes this as decentralized data management, where services own their data and publish changes for others to consume. (martinfowler.com) Another option is fanout at the edge rather than hop-by-hop inside the system. Microsoft’s architecture guidance describes an application programming interface gateway pattern that can aggregate or route client requests so internal services do not form deep chains of synchronous dependencies. (learn.microsoft.com) The argument against premature microservices is older than this week’s posts. Fowler wrote in 2015 that almost all successful microservice stories started with a monolith that was broken apart later, and he called “Monolith First” the default choice for new systems. (martinfowler.com) The database advice in those threads also tracks mainstream practice. PostgreSQL is a general-purpose relational database with built-in transactions, indexing, and replication, and Redis describes itself as an in-memory cache used to cut read latency before teams add heavier distributed infrastructure. (postgresql.org ) (redis.io) None of that means synchronous Hypertext Transfer Protocol calls are banned. Microsoft says synchronous communication is still appropriate for queries that need an immediate answer, but the guidance is to keep those paths short and avoid building a request that must survive a long chain of upstream and downstream services. (learn.microsoft.com) The practical takeaway is narrower than the slogan. Start with a monolith, a relational database, and basic caching; split services only when team boundaries or scale force it, and when you do, keep the waiting to a minimum. (martinfowler.com)