4 ms·
> Absolutely agree with 1 ("Maintain one source of truth"), not just in a service but in an architecture. Well, now you're tightly coupled against your single
by rodgerd 2y ago
> Absolutely agree with 1 ("Maintain one source of truth"), not just in a service but in an architecture.
Well, now you're tightly coupled against your single source of truth. That's a choice if you'd like your choices to be (a) more outages or (b) trying to build a perfectly available data store.
It's ironic that the example is banking; banks have many sources of truth and eventual consistency as patterns and always have.
- mvdtnz 2y agoEither way you're coupled to your data. It has to come from somewhere. The alternative is that the "origin" of the data either posts it to me (so my origin has a direct dependency on me and any other service that wants to use that data) or the origin fires events which I subscribe to, in which case I have that same tight coupling but I need to deal with circumstances where the event source fails (no one likes to talk about this but it happens, often). Not only that but if I ever want to change data I now need to somehow inform the origin that the data has changed. Coupling me even more strongly. The coupling is inherent. Things are simpler if you keep the source of truth in one place.