Domain Modeling

Any time you use the latest value of something, then adding a new value is side-effecting.

A more functional approach is for processes to use a specific value.

One pattern for storing data is content hashing. The idea is that for every value you store in a db, you also store a hash of the content. What does this get you?

1. Consistency - Say service A requests something from service B. Service B generates a response and stores the response (along with the hash) in a service-local db. Later, Service ZZZ needs to do some work using the same data. Service ZZZ calls Service B and is like: "Yo, I heard about this really cool response with hash abcd1234 you gave to service A. Can you hook me up?" Service B is like: here ya go.
2. Deduplication - A service may be called many times for the same exact thing.

If two objects have the same ID (hash), then they are the same value.

The application can be updated, and the mechanism for producing responses might change a little bit, but you still preserve the deduplication thing. When a new response has the same content as an old response, the old response will be returned.

The problem:

Without content hashing: I have ID 3, you have ID 5, turns out they are the same (in terms of content). But their IDs, being different, suggest they might be different.

Another solution: Use a redis cache, bust the cache each time you deploy. However, you'll end up producing duplicates every time the service is deployed, so not a general solution.

Cons:

• You still have to compute the response for every request. Without layering on more middleware to this solution, this approach does not save any CPU cycles.