This post didn’t address what I think is the compelling argument:
You don’t need to have One True Customer definition, but a relational database does let multiple definitions of a customer reference each other so you can know two customers are the same customer. In other words, this article is advocating duplicating data because different services might need different views but it doesn’t address why we still can’t do that in one big database.
I finde this article to be uninspiring, ill informed, and juvenile. IME there are two basic questions that ought to concern anyone; is the (business critical) data consistent? And who’s responsible for keeping it consistent? In either case, as an application developer I unequivocally REJECT that responsibility.
what happens when disparate applications really do need to know about data in other applications? … Fire off a message saying “CustomerAddressUpdated” and any other applciation that is concerned can now listen for that message and deal with it as it sees fit.
And/or you can make it so that the application maintains the events as part of its service. Then, if there’s an outage, as part of the recovery you can go read the event log and update the data as required. Any solution where event messages aren’t ephemeral will do, I think. I also think “not being able to emit an event message” should also be treated like a fairly critical incident, if you go down that path. I think many things.
Ah, you mean the publishing app - I’d thought you meant the subscriber earlier.
Treat messages the way an offline email client treats newly composed email: stick it in a queue to be sent and only remove items from the queue once read receipts have been received for them.
This requires message to be idempotent, of course.
That doesn’t address my question, though: there are two actions happening: update the data in the DB and tell people about it. The app can fail between the first and second.
This hits home. Just had this argument with my CIO last week. I never want to hear about Master data management or “one source of truth” nonsense again.
This post didn’t address what I think is the compelling argument:
You don’t need to have One True Customer definition, but a relational database does let multiple definitions of a customer reference each other so you can know two customers are the same customer. In other words, this article is advocating duplicating data because different services might need different views but it doesn’t address why we still can’t do that in one big database.
I finde this article to be uninspiring, ill informed, and juvenile. IME there are two basic questions that ought to concern anyone; is the (business critical) data consistent? And who’s responsible for keeping it consistent? In either case, as an application developer I unequivocally REJECT that responsibility.
What happens if the message drops?
PubSub should guarantee delivery.
And/or you can make it so that the application maintains the events as part of its service. Then, if there’s an outage, as part of the recovery you can go read the event log and update the data as required. Any solution where event messages aren’t ephemeral will do, I think. I also think “not being able to emit an event message” should also be treated like a fairly critical incident, if you go down that path. I think many things.
How? The application can crash between updating the data and publishing the message.
Ah, you mean the publishing app - I’d thought you meant the subscriber earlier. Treat messages the way an offline email client treats newly composed email: stick it in a queue to be sent and only remove items from the queue once read receipts have been received for them. This requires message to be idempotent, of course.
That doesn’t address my question, though: there are two actions happening: update the data in the DB and tell people about it. The app can fail between the first and second.
The message creation (e.g. postgres queue) can be part of the data transaction. Otherwise you need 2PC to guarantee the operation between two subsystems. https://en.wikipedia.org/wiki/Two-phase_commit_protocol
TL/DR: Data warehousing.
This hits home. Just had this argument with my CIO last week. I never want to hear about Master data management or “one source of truth” nonsense again.