When services communicate with each other in a microservices architecture, there are two common patterns: Sync and Async.
In Sync architecture, services call each other typically via direct API calls or other request/response methods. This means that if a service is down, all other dependent services are also down. But this pattern can simplify handling data consistency and reduce data duplication as each service can fetch data when needed.
In Async architecture, services send messages to each other via messaging systems like message queues or event streams where messages are sent without requiring an immediate response. Services are relatively independent and don’t need to wait for each other to respond. If one service fails, other services continue functioning without caring much and will process messages as they become available once the failed service is restored. But this approach usually requires data duplication and extra consistency handling mechanisms, since each service most likely needs to have its own data copy to serve independently.
It might seem like the async approach is the best choice for unicorn projects, but this isn't always the case. Whether to use Sync or Async pattern depends on various factors such as the requirements of the software, budget, market demand, etc. It's important to note that gaining one advantage usually means sacrificing another. Most large-scale software is built on a hybrid pattern to maximize optimization.
I'm building a simple application using microservices architecture in my free time for fun.
Shoot any questions you have. Stay tuned to get updates <3
Top comments (0)