other “I” words: idempotence, immutability, and interchangeability.
Identity and idempotence.
Idempotence is the property that says it’s OK
to do work more than once. If it happens at least once, the behavior is the
same as if it happens exactly once.
general, idempotence is a subjective
concept that ignores side effects outside of the plane of abstraction provided by the service.
Idempotence frequently depends
on having an identity for the work. In
many cases, you need to understand
the identity of the operation to decide
if you have done it before. There are
other cases such as reading a record
where the work is naturally idempotent
because it leaves no effects when it’s
performed. In cases where changes are
made, tracking that it’s already done
requires identity of some kind.
Sometimes, the identity used to provide idempotence is a consequence
of some connection or session. That
works until a new session arrives to retry the failed session.
Managing the requester’s identity,
the target’s identity, and the identity
of the work in question are some of the
hardest problems in scalable systems
that need idempotence.
Banks have used a simple approach
to identity an idempotence with two
˲ The transaction’s identity is the
preassigned check number.
˲ The check must typically clear in
less than one year after it was written.
The second constraint limits the list
of cleared checks the bank must maintain while preserving exactly-once processing.
Identity and immutability.
Immutability is the property that something
does not change. No matter how many
times the data is read, the same result
is returned. Immutability is the basis
for many of today’s solutions, from
low-level hardware to massively scalable solutions.
Immutability is a relationship be-
tween an identity and a result that is
Without some formalized notion of
identity, you don’t have immutability.
We may see immutable identifiers
for changing stuff.
A product ID may be fixed for years
while its description evolves.
Identity and interchangeability.
Interchangeability can be viewed as a
duality with immutability. Rather than
asking, “Is this thing identical?” to
what we had before, we ask, “Is this
thing equivalent?” to what we had before. Is it good enough?
When manufactured items are all
brand new and identical, you can be
happy taking any one of them from
the warehouse, assuming they are
not damaged. There is an identity for
the product, and that identity means
any one of them will do. They are interchangeable.
When reserving a room at a hotel,
you accept that one king-sized nonsmoking room is as good as another—even if one is next to the elevator
and really noisy. The group of rooms
labeled as king-sized nonsmoking is
considered equivalent, and there is an
identity for any one of those rooms . You
reserve one from the pool of rooms
without knowing exactly which one.
Recall that an identifier for a product
description in a product catalog refers
to an ambiguous version of the product
description. That’s OK… any one will
do, as the versions are interchangeable.
It used to be we focused on one application running on one computer accessing one SQL database. While we
may have had application-based identifiers (for example, Social Security
numbers), the underlying system was
based on values in cells. Relational algebra related values to other values.
As systems cleave apart for scale,
cleave apart to provide management
or trust boundaries, or cleave together
to integrate solutions, identifiers and
identity form the glue that binds solutions. Identities also formalize the
separation of disparate and distrusting
solutions. Cleaving apart or cleaving
together requires identities.
When we bind work together with
identities, the interesting tension is,
“What constitutes the identity?” What
precisely is identified by a king-sized
nonsmoking room? Where did we deliver the message that was guaranteed
to be delivered?
New emerging systems and proto-
cols both tighten and loosen our no-
tions of identity, and that’s good! They
make it easier to get stuff done. REST,
Io T, big data, and machine learning all
revolve around notions of identity that
are deliberately kept flexible and some-
times ambiguous. Notions of iden-
tity underlie our basic mechanisms of
distributed systems, including inter-
changeability, idempotence, and im-
Finally, don’t be too picky about
calling this identity. We see identity as
names, keys, pointers, handles, IDs,
numbers, identifiers, UUIDs, GUIDs,
document IDs, UPCs, ASINs, employee
numbers, file names, Social Security
numbers, and much more.
Truly, identity by any other name
does smell as sweet …
Pervasive, Dynamic Authentication of
Meng-Day Yu and Srinivas Devadas
How Do I Model State?
Let Me Count the Ways
Ian Foster et al.
How to De-identify Your Data
Olivia Angiuli, Joe Blitzstein, and Jim Waldo
1. Berners-Lee, T., Masinter, L. and McCahill, M.
Universal Resource Locator. Technical Report,
Internet Engineering Task Force, Draft RFC, 1994;
2. Dean, J. and Ghemawat, S. MapReduce: Simplified
data processing on large clusters. In Proceedings
of the 6th Symposium on Operating Systems Design
and Implementation 6, 10 (2004); https://dl.acm.org/
3. Fielding, R. Architectural styles and the design of
network-based software. Ph.D. dissertation. University
of California, Irvine, 2000.
4. Helland, P. The power of babble. Commun. ACM 59,
11 (Nov. 2016), 40–43; https://dl.acm.org/citation.
5. Helland, P. Idempotence is not a medical condition.
acmqueue 10, 4 (2012); https://dl.acm.org/citation.
6. Helland, P. Immutability changes everything.
acmqueue 13, 9 (2016); https://queue.acm.org/
detail.cfm?id=2884038. (First printed in the Biennial
Seventh Conference on Innovative Database Research
7. Helland, P. Data on the outside versus data on the
inside. In Proceedings of the Conference on Innovative
Database Research; http://cidrdb.org/cidr2005/
8. Helland, P. Side effects, front and center! Commun.
ACM 60, 7 (July 2017), 36–39; https://dl.acm.org/
Pat Helland has been implementing transaction systems,
databases, application platforms, distributed systems,
fault-tolerant systems, and messaging systems since
1978. He currently works at Salesforce.
Copyright held by author/owner.
Publication rights licensed to ACM.