In a distributed system, we often need to store data that we do not own. We might use it as a unique identifier across domains or the system we do own needs to proxy it to yet another service.
In many cases, the origin system exposes it in the same way it is represented internally, for instance: a foreign key name of a relational database:
|elixir, ruby, python
Translated to JSON, we could send it over the wire as follows:
A service consuming the information may want to add prefixes to scope it for “companies” and store/cache it like so:
|elixir, ruby, python
But here’s the problem: as engineers, we look at
_id fields and immediately
think of it as integers representing a unique way to reference something.
However, the consuming service has no control over
the data it receives and the data type is only assumed.
If you use that distributed ID field as a local foreign key: some external system controls the value and an unforeseen change might break our setup.
I have had good experiences using the pattern
*_identifier instead. It indicates that…
- it is some kind of a unique identifier
- some other system has control over it
*_identifier value is to be stored, it should always be saved as a
string type. Almost anything can be coerced into a string, and that way we
guarantee that the origin system can choose whatever they want for their unique
This is particularly true if the origin system decided to move to using UUIDs. A final version of the local relational table above could look like this:
If the system exposing the data is controlled by your organisation, we can support this at the source.
It is a common pitfall of API designs, especially RESTful APIs, to expose a resource exactly like you represent it in your database. This makes sense to reduce the cognitive load of the team maintaining the API. However, the data layer will inevitably change, rendering this point moot: the DB representation has to be translated to maintain a stable contract. Why not abstract from the data layer to begin with and name the keys in the payload in a system-agnostic way?
*_idfields for externally owned data
- Prefer a string type over integer for
- Avoid a 1:1-map of your persistence model to your external API