Over a million developers have joined DZone.
{{announcement.body}}
{{announcement.title}}

Data Ownership: The Story of an Invoice

DZone's Guide to

Data Ownership: The Story of an Invoice

This article tells a story about a shoe store owner and how he has installed a sync service between all the stores and how this system is not efficient.

· Database Zone ·
Free Resource

RavenDB vs MongoDB: Which is Better? This White Paper compares the two leading NoSQL Document Databases on 9 features to find out which is the best solution for your next project.  

Image title

Let’s talk about Gary and Gary’s shoes. Gary runs a chain of shoe stores across the nation. As part of refreshing their infrastructure, Gary wants to update all the software across the entire chain. The idea is to have a unified billing, inventory, sales, and time tracking for the entire chain.

Gary doesn’t spend a lot of time on this (after all, he has to sell shoes), he just installed a sync service between all the stores and HQ to sync up all the data. Well, I call in sync service. What it actually turns out to be is that the unified system is a set of Excel files on a shared DropBox folder.

Feel free to go and wash your face, have a drink, take Xanax. I know it might be a shock to see something like this.

Surprisingly enough, this isn’t the topic of my post. Instead, I want to talk about data ownership here.

Imagine that one of Gary’s stores in Chicago sold a bunch of shoes, then issued an invoice to the customer. They dutifully recorded the order in the Orders.xlsx file with the status “Pending Payment.”

That customer, however, accidentally sent the check to the wrong store. No biggie, right? The clerk at the second store can just go ahead and update the order in the shared system, marking it as “Paid in full.”

As it turns out, this is a problem. And the easiest way to explain why is data ownership. The owner of this particular record is the original store. You might say that this doesn’t matter, after all, the change happened in the same system. But the problem is that this is almost always not the case.

In addition to the operation “system” that you can see on the right, there are other things. The store manager still has a PostIt note to call that customer and ask about the missing payment. The invoice that was generated needs to be closed, etc. Just updating it in the system isn’t going to cause all of that to happen.

The proper way to handle that is to call the owner of the data (the original store) and let them know that the check arrived at the wrong store. At this point, the data owner can decide how to handle that new information, apply whatever workflows need to be done, etc.

I intentionally used what looks like a toy example, because it is easy to get bogged down in the details. But in any distributed system, there are local processes that happen, which can be quite important. If you go ahead and update their information behind their back, you are guaranteed to break something. And I haven’t even begun to talk about the chance for conflicts… of course.

Get comfortable using NoSQL in a free, self-directed learning course provided by RavenDB. Learn to create fully-functional real-world programs on NoSQL Databases. Register today.

Topics:
database

Published at DZone with permission of

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}