Lesson 43 - Microservices Orchestration Pattern

Поділитися
Вставка
  • Опубліковано 15 лис 2024

КОМЕНТАРІ • 18

  • @ananths5905
    @ananths5905 4 роки тому +1

    I must thank you a million! Your channel is binge worthy and about to pay me aplenty

    • @markrichards5014
      @markrichards5014  4 роки тому

      Thanks for your kind words and encouragement Wabi!! I hope you are enjoying the series.

  • @suraj-chhetry
    @suraj-chhetry 5 років тому +1

    Thank you so much for sharing your ideas . Waiting for more patterns on Microservices Orchestration Pattern

  • @ZephonEx
    @ZephonEx 4 роки тому

    Amazing explained! Just the channel I was looking for. Thanks!’

  • @mrsbootsworkouts
    @mrsbootsworkouts 11 місяців тому

    Thank you!! Very informative

  • @davideb4258
    @davideb4258 2 роки тому

    So, in short, the API layer interacts with single microservices for "simple" operations that do not require aggregation (or, put in another way, for operations that are limited to a single microservice), while for the others we'd use separated microservices that act as orchestrators, right?

    • @markrichards5014
      @markrichards5014  2 роки тому +1

      Correct; the API Layer is a single request that goes to the orchestrator service, which then splits the single business request into multiple individual service requests and coordinates them.

  • @pankajsinghv
    @pankajsinghv 5 років тому

    Excellent explanation of Microservices Orcehstrator pattern. I believe this is also called Sage Pattern?

    • @markrichards5014
      @markrichards5014  5 років тому +2

      Keen of you to spot the similarities. The answer is "Sort of"; Sagas do not have to be orchestrated - they can be choreographed as well. Sagas denote a specific business transaction context which spans multiple services, whether they are orchestrated or choreographed via "direct" interservice communication (direct meaning via the restful API layer or via messaging or RPC).

  • @danielsouza6154
    @danielsouza6154 3 роки тому

    Amazing great great thanks a lot.

  • @saileedas772
    @saileedas772 Рік тому

    Does the orchestration microservice have its database,
    or since all the other microservices have its own database,orchestration microservice does not need to have a database for optimization

    • @markrichards5014
      @markrichards5014  Рік тому +1

      It might have its own database if it is persisting the workflow state (which is usually a good thing to do in the event of a crash).

    • @saileedas772
      @saileedas772 Рік тому

      ​@markrichards5014 In the orchestration microservice, how do we send the data ,if the data is sent partially and it fails midway,
      how to send the remaining data?
      Where the partial data sent successfully is stored?
      Partial data sent can be saved in savepoint of the database of the orchestration layer if there is one separate db for orchestration. But
      if there is no db for the orchestration, how is the partially sent data saved?

    • @markrichards5014
      @markrichards5014  Рік тому +1

      @@saileedas772 Generally the orchestration service would have it's own schema or database to store the state, and updates it each time the state changes.

  • @prashantjha439
    @prashantjha439 4 роки тому

    API gateway as ESB ?....Aren't API gateway simply reverse proxies (Edge proxies or Envoy L7 proxy ?)........

    • @markrichards5014
      @markrichards5014  4 роки тому +1

      Not always - A gateway can (and usually does) contain the cross-cutting concerns (unless you are using a service mesh, which in that case those cross cutting concerns are handled by the mesh). So: API Reverse Proxy -> Service Mesh or API Gateway. Sometimes I've seen an API reverse proxy front a gateway (the gateway being used for cross cutting concerns). Note here when I say "ESB" I referring to the actual product, not the role of the gateway.