3 ms·

> Communication with other SCSs or 3rd party systems is asynchronous wherever possible. Specifically, other SCSs or external systems should not be accessed sync

by shock 6y ago

> Communication with other SCSs or 3rd party systems is asynchronous wherever possible. Specifically, other SCSs or external systems should not be accessed synchronously within the SCS's own request/response cycle. This decouples the systems, reduces the effects of failure, and thus supports autonomy. This is some seriously bad advice. First, asynchronous code is much harder to get right, from a correctness point of view. Second, it is much more complex both in the technical aspects as well as in cognitive complexity. Then, simply by virtue of being asynchronous they don't become decoupled as suggested in the quote. I urge everyone to think for themselves before following the advice in this so-called "architecture".

biaachmonkie 6y ago
I read that section not to suggest using async coding patterns such as async/await, futures, etc.. Because that still relies on the external system in the request/response of the SCS. Instead I read that to suggest having all the data needed to serve a request with data you have cached/stored in an asynchronous manor via method that is not in the request/response path that uses it. For a system may refresh account/customer data every hour from an external system/database and cache it, or receive push updates from the external system to update records that have changed. That way if external system is unavailable it doesn't effect the SCS's ability to serve the request with cached data instead of failing the request if it was relying on the external system being available. That is very useful for lots of scenarios where the data does not change frequently or you can tolerate stale data. Lots of scenarios can benefit from that pattern to increase reliability at the expense of having a change propagate slowly to systems that use it.
- lliamander 6y ago
  I think I have the same reading of the source that you do, but let me give a concrete example to see if we are in agreement. Suppose you need to place an order to the order fulfillment system, but that requires data from the user preferences, product catalog, and geolocation services. A typical approach would be to have the order fulfillment system call those other systems to get the data it needs. According to SCS, the UI would be responsible for fetching that data from the other systems, and would pass all of it as part of the payload to the order fulfillment service. I think that's a perfectly reasonable approach, but I do have some questions/concerns: - This would make the API for the order fulfillment system more complex - I don't quite understand how integration would work at the UI level if each of these systems (fulfillment, preferences, etc.) have their own UIs. I'm not saying it's not possible, I just don't have enough client-side experience to fully visualize. - it seems that some level of integration at the logic layer is inevitable. Consider an order fulfilmment system that needs to interact with a third party provider.
  - okbake 6y ago
    > According to SCS, the UI would be responsible for fetching that data from the other systems, and would pass all of it as part of the payload to the order fulfillment service. One potential issue is that the order fulfillment service still needs to validate that the data its getting from the client is correct. For example, even if you send a list of full product details rather than a list of productIds to create the order, the fulfillment service still need a way to associate the Order entity with the Product entities. You could also send the ID with each of the products, but how would you know if the product has since been deleted or otherwise doesn't exist. You end up needing the order service to either have its own set of knowledge about what products exist in the system for that user, or you need to make the synchronous call to ensure they're real products.
    - lliamander 6y ago
      Good point. The solution is obviously going to be context-specific. I suspect in our hypothetical order scenario that the order fulfillment system could get away with not validating the product being ordered. Of course it would still need a way of capturing the identity of that product. I would guess that the best way to handle that would be to pass a URN or URI for the product. That would still decouple it somewhat from the product catalog system. In general for these kinds of integrations, you're probably better off avoiding passing around system specific IDs. Pass data instead of IDs (pass the geocordinates or standardized address for a customers delivery address rather than the customer ID). If you have to pass around IDs, then URIs allow for greater decoupling.

by shock 6y ago

biaachmonkie 6y ago

I read that section not to suggest using async coding patterns such as async/await, futures, etc.. Because that still relies on the external system in the request/response of the SCS. Instead I read that to suggest having all the data needed to serve a request with data you have cached/stored in an asynchronous manor via method that is not in the request/response path that uses it. For a system may refresh account/customer data every hour from an external system/database and cache it, or receive push updates from the external system to update records that have changed. That way if external system is unavailable it doesn't effect the SCS's ability to serve the request with cached data instead of failing the request if it was relying on the external system being available. That is very useful for lots of scenarios where the data does not change frequently or you can tolerate stale data. Lots of scenarios can benefit from that pattern to increase reliability at the expense of having a change propagate slowly to systems that use it.

lliamander 6y ago
I think I have the same reading of the source that you do, but let me give a concrete example to see if we are in agreement. Suppose you need to place an order to the order fulfillment system, but that requires data from the user preferences, product catalog, and geolocation services. A typical approach would be to have the order fulfillment system call those other systems to get the data it needs. According to SCS, the UI would be responsible for fetching that data from the other systems, and would pass all of it as part of the payload to the order fulfillment service. I think that's a perfectly reasonable approach, but I do have some questions/concerns: - This would make the API for the order fulfillment system more complex - I don't quite understand how integration would work at the UI level if each of these systems (fulfillment, preferences, etc.) have their own UIs. I'm not saying it's not possible, I just don't have enough client-side experience to fully visualize. - it seems that some level of integration at the logic layer is inevitable. Consider an order fulfilmment system that needs to interact with a third party provider.
- okbake 6y ago
  > According to SCS, the UI would be responsible for fetching that data from the other systems, and would pass all of it as part of the payload to the order fulfillment service. One potential issue is that the order fulfillment service still needs to validate that the data its getting from the client is correct. For example, even if you send a list of full product details rather than a list of productIds to create the order, the fulfillment service still need a way to associate the Order entity with the Product entities. You could also send the ID with each of the products, but how would you know if the product has since been deleted or otherwise doesn't exist. You end up needing the order service to either have its own set of knowledge about what products exist in the system for that user, or you need to make the synchronous call to ensure they're real products.
  - lliamander 6y ago
    Good point. The solution is obviously going to be context-specific. I suspect in our hypothetical order scenario that the order fulfillment system could get away with not validating the product being ordered. Of course it would still need a way of capturing the identity of that product. I would guess that the best way to handle that would be to pass a URN or URI for the product. That would still decouple it somewhat from the product catalog system. In general for these kinds of integrations, you're probably better off avoiding passing around system specific IDs. Pass data instead of IDs (pass the geocordinates or standardized address for a customers delivery address rather than the customer ID). If you have to pass around IDs, then URIs allow for greater decoupling.