4 ms·

By mentioning data consistency and transactions - your microservice is supposed to be self-contained and self-sufficient, doing its own job only. True, it may r

By mentioning data consistency and transactions - your microservice is supposed to be self-contained and self-sufficient, doing its own job only. True, it may rely on other service, but not in the way that the two services would do the exact same job together as if you're invoking a `private` method helpers. For ex., filling a shopping cart should be its own thing. Searching for stuff to fill that cart can be another service that is just a dumb catalog. No data consistency problems here.

Volundr 6y ago
Sure there is. What do I do when a piece of information I need to fill the shopping cart is removed or renamed in the search service?
- sto_hristo 6y ago
  There is always the single source of truth principle. It is expected that both the search service and cart reference the catalog service.
  - Volundr 6y ago
    OK, so when the catalog service is updated I need to update the search service and the cart service and coordinate deployment of these various services, or provide multiple versions of the catalog api.
    - sto_hristo 6y ago
      Yes. If you have several consumers of the catalog service, those consumers are bound to a specific version it. You may update the catalog service API as much as you wish, but that will simply open /v2, v3, .../ endpoints - existing services shouldn't be affected. Just like with regular REST APIs. Deprecation of older API versions will be as disrupting as expected, of course. If existing consumer of catalog service needs to make use of the new version features, you update it on its own... Version hell? You can imagine the horrors. But technical debt on an architectural level is something you need to consider any architecture you choose to create your application in. Point of micro services is have your components loosely coupled and independent from one another. If catalog fails, it shouldn't bring down the whole application with it. In our simple example, catalog failure means whole app becoming inert, but in bigger applications you _may_ find benefits of this. Also worth mentioning - load can vary between components. The cart will see less use than the search service, while the catalog will be most loaded. You can make deployment decisions to optimally allocate resources for your application.

Volundr 6y ago

Sure there is. What do I do when a piece of information I need to fill the shopping cart is removed or renamed in the search service?

sto_hristo 6y ago
There is always the single source of truth principle. It is expected that both the search service and cart reference the catalog service.
- Volundr 6y ago
  OK, so when the catalog service is updated I need to update the search service and the cart service and coordinate deployment of these various services, or provide multiple versions of the catalog api.
  - sto_hristo 6y ago
    Yes. If you have several consumers of the catalog service, those consumers are bound to a specific version it. You may update the catalog service API as much as you wish, but that will simply open /v2, v3, .../ endpoints - existing services shouldn't be affected. Just like with regular REST APIs. Deprecation of older API versions will be as disrupting as expected, of course. If existing consumer of catalog service needs to make use of the new version features, you update it on its own... Version hell? You can imagine the horrors. But technical debt on an architectural level is something you need to consider any architecture you choose to create your application in. Point of micro services is have your components loosely coupled and independent from one another. If catalog fails, it shouldn't bring down the whole application with it. In our simple example, catalog failure means whole app becoming inert, but in bigger applications you _may_ find benefits of this. Also worth mentioning - load can vary between components. The cart will see less use than the search service, while the catalog will be most loaded. You can make deployment decisions to optimally allocate resources for your application.