Understanding the concept of data immutability

In computer science, immutability is a key concept when it comes to data storage and processing, and it's also a concept found in programming.

Immutable data (called "immuable" in French) is data that cannot mutate, meaning it can never be modified.

Sometimes, this data cannot even be destroyed.

What's the point?

The concept of immutable data is essential in our digital world, but not only there. We also find dozens of examples of immutable data (or documents) in the "real" world (meaning "everyday" life).

In both cases, the purpose is the same.

This allows us to have a source of truth to rely on when making important decisions, based on reliable data, frozen in time, whose history can be traced.

A few examples

To prove to you that immutable data can be found everywhere, here is a very varied (non-exhaustive) list:

• A sales deed for real estate property is an immutable document once signed
• An invoice is immutable (must be canceled by a credit note)
• The amount, recipient, and origin of a bank transfer (if there's an error, a transfer must be made in the opposite direction)
• The content of an RFC (must be modified by another RFC)

It's also the principle of immutability that makes the concept of blockchain so powerful.

Sometimes, the immutability of a piece of data, or a document, is technically ensured. This is the case with blockchain, which ensures the authenticity and immutability of transactions through its control of the hash of each previous block.

And other times, it's a third party that ensures the immutability of the document (like a notary for a sales deed).

How do you modify immutable data?

The simple answer is: it's not possible.

But in reality, that's not a problem, because we're not going to directly change our data, but rather associate changes with it.

The line seems thin, and yet it makes all the difference

Let's take a concrete example: accounting. Don't leave, you'll see, it's very simple.

In accounting, an invoice issued by a company is immutable, it can neither be canceled, deleted, nor modified.

Yet, to err is human, so you could very well make a big mistake when creating your invoice. Let's imagine that instead of billing 1000€, you issue an invoice for 10000€.

If an invoice weren't immutable, it could be destroyed, and another one created.

Except that would open the door to fraud, to phantom invoices, and we could no longer trust the accounting history.

So how do you correct your mistake? It happens in three steps:

• We keep a history of our erroneous invoice
• We create a new document called a "credit note", it's like an invoice but with a negative amount, in this case, the same amount as our previous invoice, which will cancel out the amount owed by the client (called the receivable)
• Then we recreate an invoice with the correct figure, which the client will have to pay

In this example, each document is immutable, we can correct our mistakes, modify the final state of our transaction, but our modification history will always remain authentic and verifiable.

In this case, it's our accounting software that will partly ensure this immutability by preventing document modifications and deletions.

Technical implementations

Now that we understand how immutability works as a whole, let's look at some technical concepts based on immutability in computer science/programming.

Rust

Indeed, by default in Rust, when you create a variable, it is actually immutable. For example, with the following code:

let x: i32 = 42;
x = 10;

Error: re-assignment of immutable variable `x`

Because every declared variable is immutable by default

To make a variable mutable, you need to explicitly declare it with the mut keyword, like this:

let mut x: i32 = 42;
x = 10;
println!("{}", x);

Event Sourcing

There are also databases that work on this principle, this is what's called event sourcing.

Instead of storing data in a table (for example, users) through queries that alter the table's content, events must be stacked, in the form of commands:

• Adding a resource
• Adding a resource modification

For example:

• I add a user John Doe
• I add a modification of his age with the value 25
• I add a modification of his age with the value 35 because I made a mistake, but the previous state remains accessible in the database
• Finally, I cannot delete my user, but I can mark him as deleted, or disabled, which is what's called "soft-delete"

Git

Finally, to end this list of examples, what better than a tool you use daily that works on the immutability of each of its states: Git.

Each new version of the code is actually just a list of changes between the old version and the new one, with additions, deletions, and modifications.

Note that it is possible to "forcibly" remove certain files from the history for security reasons

Because Git's goal is not to be a legal source of truth for code, but simply to facilitate version management.