Summary: Data And Communication Patterns For Microservices

Read the summary and the most important questions on Data and Communication Patterns for Microservices

• 1 Monoliths vs Microservices

• The general idea of the API composition pattern ?

  
  If you need to aggregate data from multiple services, you call their APIs, retrieve the data, and aggregate it in your service
  You call the other services from which you need to retrieve the data, process it, and return it to the caller. And you do that each time your service gets called. You don‘t store any of the retrieved information in your database.

• Which strong dependencies is API composition introducing ?

  
  needs to know the IP address and port numbers of the other services.
  if the other services go down, the dependent Service goes down as well.
  if any of these services are slow to respond, it will directly affect the response time of the dependent Service.

• Other drawbacks API composition ?

  
  merge operation can be inefficient because the responses of the otherservices are often not optimized for your specific use case
  
  service calls don’t share a transactional context

• 2 Synchronous Service Calls

• 2.1 API Composition

• The general idea of the API composition pattern ?

  If you need to aggregate data from multiple services, you call their APIs, retrieve the data, and aggregate it in your service

• The main issue with the API composition pattern ?

  1. The calling service always needs to know the IP address and port numbers of the other 3 services.
  2. If any of the other services go down, the calling service goes down as well.

  1. If any of these services are slow to respond, it will directly affect the response time of the calling service.

• Another potential downsides of the API composition pattern

  
  you’re often requesting data from multiple services, which you then need to merge in memory. This merge operation can be inefficient because the responses of the other services are often not optimized for your specific use case
  
  service calls don’t share a transactional context

• 2.2 Circuit Breaker

• The general idea of the circuit breaker pattern ?

  You monitor each request to another service, and as soon as it becomes unavailable or unresponsive, you use a fallback instead of executing additional requests.

• 2.3 Service discovery

• The service registry pattern solves which common issue ?

  your clients no longer need to know where they can find an instance of the required services. It only needs the name of the service, and it needs to be able to do a lookup in the service registry.

• 4 Asynchronous Service Calls

• 4.1 Event Driven

  This is a preview. There are 3 more flashcards available for chapter 4.1
  Show more cards here

• Why does a service produce a relatively broad set of data ?

  The event producing and the event consuming services are independent of each other. The event generating service doesn’t know which services consume the event or which information they need The event consuming service can decide which of the provided information it needs.

• 4.2 Domain events

  This is a preview. There are 1 more flashcards available for chapter 4.2
  Show more cards here

• General idea of domain events ?

  
  events should represent something that happened in the domain of the producing service
  an event should have semantic meaning
  The event simply describes what had happened in the business domain.