"Fake autonomy" and the delusion of autonomous services

[SlurrerOfSpeech]

Let's say I run an ecommerce business and I have one service for handling shipping and another service for handling customer profiles such as name, address, age, etc. Call them Customer Management Service and Shipping Service.

SS has an interest in knowing the customer address of which CMS is the source of truth. One way it can get this information is whenever it needs it, with a "get customer info by id" API call.

Many software architectures will say that design creates a "dependency" of SS on CMS and that the dependency could be broken if only CMS published an "address changed" event and SS subscribed to the event and updated its internal copy of the customer address.

Ok, true, now if CMS is down SS can continue to operate. It is "independent" in some sense.

But, does this solve any problem for the entire system? Look at the bigger picture. If CMS service is down, the messages aren't arriving, and we're potentially shipping out products to the wrong addresses. This will need fixed. In fact, this is probably worse than if we couldn't ship anything due to the CMS being down.

 

[phinds]

Everything you say is true (almost, see below), but what's your point? Terminology is really irrelvant. What matters is whether or not your system gets the job done properly.

And by the way having an address update service alone is insufficient. You'd need coordination (automated or manual) such that the SS does not run before the CMS is complete so that it HAS an address, and that address is not really an update (a change of address), its an addition.

The best way to deal with it is to have the customer data in a database that is accessible to both systems, but even then you have to make sure the SS doesn't try to run first.

 

[Filip Larsen]

There are many ways you can resolve downtime of one service needed by other services, but the specific example you describe make little sense to me. You describe this strange system where customer orders are finalized by (or sent to) the SS without the customer approving his shipping address (i.e. that the shipping address is not part of the order data) and then that the SS due to CMS downtime decides to use an old cached address. I would question why SS would have customer addresses (separate from orders) in the first place, why SS don't just wait for CMS to come back up, and how the customer can change his address if CMS is down? Even if SS maintained a local address DB updated by push-data from CMS there should be a keep-alive signal to let SS know it is not currently receiving from CMS and that any local addresses may be stale. I mean, if you describe a system that is ill-designed then, almost by definition, it is not too surprising that it can fail to work as intended in some cases.

In general, if failure of a service is fatal for other services that have to process data in a time critical manner you would probably make steps to ensure the dependent service has a fail-over mode or similar, perhaps even in hot-swap mode. Such a service and its communication protocols are not trivial to design right. On the other hand, if a failure is not time-critical for other services one could also just wait for the service to come back up. In any case, each service can (if really needed) still be defined and operated in an manner that appears autonomous for other dependent services.

In case I have completely misunderstood your question perhaps you could describe what you consider an autonomous system to be and what "condition" in that you think gets broken?

 

[pasmith]

I think this is backwards: the CMS pulls data from the purchasing system, not vice-versa.

The idea that a customer has exactly one shipping address associated with them at any given time is false: a single customer may have a primary home address, a holiday home address, a work address, and the addresses of the people they regularly send gifts to. Corporate customers may have multiple sites to which they want orders delivered. Even the idea that there is a single billing address at any given time is probably false.

Fulfilling an order is part of a transactional process, which is backed by a transactional system. The shipping address is data associated with the purchase order header. The billing address, which is probably what the CMS actually wants to look at, is also data associated with the purchase order header (and subsequently the invoice header).

A CMS tends generally to be used for business intelligence and marketing, and pulls data from a data warehouse which is populated by looking at the data from multiple transactional systems, working out which master customer record each relates to, and whether data associated with that master record should be updated as a result.

Now you might try to make life easier for the customer by allowing them to select from a list of addresses which they have used before, if you can identify them with sufficient certainty - which is likely only the case if they have registered an account and are logged in. But that's not essential to the fulfilment process: The purchase order record has a shipping address attached to it, and the fulfilment system doesn't know or care whether the customer selected that from a list of previously entered addresses obtained from the CMS or whether the customer typed it in manually.