DEV Community: Rasmus Larsson

On Making Impossible States Impossible

Rasmus Larsson — Mon, 01 Dec 2025 16:16:26 +0000

"Inconceivable!" - Vizzini

"You Keep Using That Word, I Do Not Think It Means What You Think It Means" - Inigo Montoya

Dog year ages ago Richard Feldman held a great talk about making impossible states impossible that has influenced my thinking on this topic since, including how I at the time modeled the XML we were using in the app I was working on.

Here I aim to dig into and list some of the symptoms I've come across and how to remove them.

The examples are in TypeScript and Gleam but the concepts should be broadly applicable to any language/specification that has a decently strong type system.

If you dig Elm or Gleam like me but these concepts are new to you, I can recommend checking out either Gleam's opaque types and phantom types, or Elm's opaque types and phantom types.

If you're more TypeScript inclined then it's worth reading up on how branded types work in TypeScript.

If you find any errors or have any examples that I haven't covered, please let me know.

Gentle Introduction
Patterns of Impossible States
- Impossible Data Structures
  - Different Entity States/Sub-types with Different Field Requirements
  - Mutually Exclusive Fields
  - Mutually Inclusive Fields
  - Triple Value Boolean
  - Illegal Boolean Combinations
- The Hidden Failure State
- Constrained Values
  - Collections with Mandatory Values
  - Context Dependency
  - Constrained Value or Mutually Constrained Values
- Private Data
- Invalid State Transitions

Gentle Introduction

Now, a gentle introduction to what is meant by impossible states for those of you who didn't take the time to watch the talk.

// ❌
type Payment = { method: "card" | "cash"; cardNumber?: string };

// allows an impossible state
const p: Payment = { method: "cash", cardNumber: "1234" };

What happens if a downstream system forgets to check method and only looks for cardNumber? And can we avoid this all together?

// ✅ Better type safety.
type Payment = { type: "cash" } | { type: "card"; cardNumber: string };

const p: Payment = { type: "cash", cardNumber: "1234" };
//                                 ^^^^^^^^^^
// Object literal may only specify known properties,
// and 'cardNumber' does not exist in type '{ type: "cash"; }'.ts(2353)

The Gleam version actually turns out shorter and simpler in the more refactored version unlike TypeScript's.

// ❌
pub type Payment {
  Payment(
    method: PaymentMethod,
    card_number: Option(String),
  )
}

pub type PaymentMethod {
  Card
  Cash
}

// allows an impossible state
pub fn bad_cash_payment() -> Payment {
  Payment(Cash, Some("1234"))
}

// ✅ Better type safety.
pub type BetterPayment {
  Cash
  Card(card_number: String)
}

// Cash can never have a card number.
pub fn cash_payment() -> BetterPayment {
  Cash
}

Patterns of Impossible States

Even though the idea may now be clear, to actually get into the mindset when producing code, and also spotting them, it helps having patterns. I've attempted to categorize them as best as possible.

Impossible Data Structures

Impossible data structures can usually be re-modeled to eliminate the impossible states. Often these impossible states can be spotted by the existence/over-existence of optional fields.

Different Entity States/Sub-types with Different Field Requirements

Common with fields like 'state' or 'status' or when sub-typing class hierarchies (vehicles, animals etc.).

// ❌ too many optional fields ⇒ impossible states allowed
interface Article {
  state: "draft" | "published" | "archived";
  title: string;
  body: string;
  publishedAt?: string;
  comments: Comment[];
  archivedReason?: string;
  archivedAt?: string;
}

// ✅ Impossible states eliminated
type Article =
  | {
      state: "draft";
      title: string;
      body: string;
    }
  | {
      state: "published";
      title: string;
      body: string;
      publishedAt: string;
      comments: Comment[];
    }
  | {
      state: "archived";
      archivedReason: string;
      archivedAt: string;
    };

// ❌ too many optional fields ⇒ impossible states allowed
pub type BadArticle {
  BadArticle(
    state: ArticleState,
    title: String,
    body: String,
    published_at: Option(String),
    comments: List(Comment),
    archived_reason: Option(String),
    archived_at: Option(String),
  )
}

pub type ArticleState {
  DraftState
  PublishedState
  ArchivedState
}

pub type Comment {
  Comment(body: String)
}

// ✅ Impossible states eliminated
pub type Article {
  Draft(title: String, body: String)
  Published(title: String, body: String, published_at: String, comments: List(Comment))
  Archived(archived_reason: String, archived_at: String)
}

Mutually Exclusive Fields

// ❌ mutually exclusive optional fields that can co-exist
interface Auth {
  password?: string;
  oauthToken?: string;
}

// ✅ Impossible states eliminated
type Auth = { method: "password"; password: string } | { method: "oauth"; oauthToken: string };

// ❌ mutually exclusive optional fields that can co-exist
pub type BadAuth {
  BadAuth(password: Option(String), oauth_token: Option(String))
}

// ✅ Impossible states eliminated
pub type Auth {
  Password(password: String)
  Oauth(oauth_token: String)
}

Mutually Inclusive Fields

// ❌ Config is required if enabled is true
interface X {
  enabled?: boolean;
  config?: { foo: number };
}

// ✅ Impossible states eliminated
type X = { enabled: false } | { enabled: true; config: { foo: number } };

// ❌ Config is required if enabled is true
pub type BadConfig {
  BadConfig(enabled: Option(Bool), config: Option(Config))
}

pub type Config {
  Config(foo: Int)
}

// ✅ Impossible states eliminated
pub type X {
  Disabled
  Enabled(config: Config)
}

Triple Value Boolean

// ❌ What does 'hasAcceptedTerms: null' mean?
interface User {
  hasAcceptedTerms?: boolean;
}

// ✅ Clear communication of meaning
interface User {
  termsStatus: "accepted" | "rejected" | "pending";
}

// ❌ What does `has_accepted_terms: None` mean?
pub type BadUser {
  BadUser(has_accepted_terms: Option(Bool))
}

// ✅ Clear communication of meaning
pub type TermsStatus {
  Accepted
  Rejected
  Pending
}

pub type User {
  User(terms_status: TermsStatus)
}

Illegal (Boolean) Combinations

The boolean combinations are probably the easiest to spot but other illegal combinations can occur too, such as enums (a model of exchange rates like EUR/USD should disallow EUR/EUR).

// ❌ Can a door be open and locked at the same time?
interface Door {
  isOpen: boolean;
  isLocked: boolean;
}
// ✅ No it cannot
type Door = { state: "open" } | { state: "closed" } | { state: "locked" };

// ❌ Can a door be open and locked at the same time?
pub type BadDoor {
  BadDoor(is_open: Bool, is_locked: Bool)
}

// ✅ No it cannot
pub type Door {
  Open
  Closed
  Locked
}

The Hidden Failure State

In some cases it's handy to actually model the failure state instead of bubbling up an Exception or similar, especially when working in the frontend and you want to show something meaningful to the user.

Case in point from a TypeScript project I'm working on. An entity can have a template associated with it and we want to show a button if it does, but the template comes from a different endpoint. In our frontend the evolution was:

// ❌ doesn't really cover all the cases
const hasTemplate: boolean | undefined

// ⚠️ Somewhat better
const hasTemplate: 'loading' | 'not-found' | 'found'

// ✅ Covers all the states
const templateState: 'loading' | 'not-found' | 'found' | 'failed'

Now we can show something useful regardless of the outcome and we don't have to guess what undefined means.

This scenario is so common that there are ready-made libraries for this such as Elm's RemoteData:

type RemoteData e a
    = NotAsked
    | Loading
    | Failure e
    | Success a

Constrained Values

Constrained values, values that typically have constraints that are outside the reach of the type system, tend to require specialized functions/constructors to solve.

Collections with Mandatory Values

Collections that have mandatory values can usually be re-modeled as records with mandatory fields.

// ❌ Still allows an empty array.
type NonEmptyArray<T> = T[];

// ✅ Impossible states eliminated
type NonEmptyArray<T> = { first: T; rest: T[] };

// Implement the functions you need.
/**
 * Returns the last element if length > 1,
 * else undefined.
 */
function new_non_empty_array<T>(first: T, rest: T[]): NonEmptyArray<T> {
  return { first, rest };
}

function to_array<T>(nea: NonEmptyArray<T>): T[] {
  return [nea.first, ...nea.rest];
}

// ❌ Still allows an empty list.
pub type BadNonEmptyList(a) {
  BadNonEmptyList(List(a))
}

// ✅ Impossible states eliminated
pub opaque type NonEmptyList(a) {
  NonEmptyList(first: a, rest: List(a))
}

pub fn new(first: a, rest: List(a)) -> NonEmptyList(a) {
  NonEmptyList(first, rest)
}

pub fn to_list(nea: NonEmptyList(a)) -> List(a) {
  [nea.first, ..nea.rest]
}

Context Dependency

When a certain context is required, such as in a child-parent relationship.

// ❌ Child can exist without parent
interface Child {
  parentId?: string;
  value: number;
}

// ✅ Require constructor that supplies the parent
interface Parent {
  id: string;
}

interface Child {
  parent: Parent;
  value: number;
}

function makeChild(parent: Parent, value: number): Child {
  return { parent, value };
}

// ❌ Child can exist without parent
pub type BadChild {
  BadChild(parent_id: Option(String), value: Int)
}

// ✅ Require constructor that supplies the parent
pub type Parent {
  Parent(id: String)
}

pub type Child {
  Child(parent: Parent, value: Int)
}

pub fn make_child(parent: Parent, value: Int) -> Child {
  Child(parent, value)
}

Constrained Value or Mutually Constrained Values

These are values that are by themselves or collectively required to satisfy some business rule.

// ❌ Not guaranteed to be positive
interface X {
  quantity: number;
}

// ✅ Uses brand types to ensure
type Positive = number & { __brand: "Positive" };

function makePositive(n: number): Positive | Error {
  return n > 0 ? (n as Positive) : new Error("Not positive");
}

interface X {
  quantity: Positive;
}

// ❌ Does not guarantee start <= end in and of itself
interface Interval {
  start: Date;
  end: Date;
}

// ✅ combine with a branded type
function makeInterval(start: Date, end: Date): Interval | Error {
  if (end < start) return new Error("Invalid interval");
  return { start, end };
}

// ❌ Not guaranteed to be positive
pub type BadX {
  BadX(quantity: Int)
}

// ✅ Uses an opaque type to ensure positivity
pub opaque type Positive {
  Positive(Int)
}

pub fn make_positive(n: Int) -> Result(Positive, String) {
  if n > 0 {
    Ok(Positive(n))
  } else {
    Error("Not positive")
  }
}

pub type X {
  X(quantity: Positive)
}

// ❌ Does not guarantee start <= end in and of itself
pub type Interval {
  Interval(start: Int, end: Int)
}

// ✅ smart constructor enforces the invariant
pub fn make_interval(start: Int, end: Int) -> Result(Interval, String) {
  if end < start {
    Error("Invalid interval")
  } else {
    Ok(Interval(start, end))
  }
}

Private Data

Data that should not be exposed/available. This can be solved using branded types or private fields in TypeScript, and opaque types in Gleam/Elm.

// using branded types
type UserId = string & { readonly brand: unique symbol };

function makeUserId(s: string): UserId {
  return s as UserId;
}

// using TypeScript's private keyword
class BankAccount {
  private balance = 100;
}

new BankAccount().balance; // ❌ Compile-time error
// ⚠️ but still available at runtime so JSON.stringify(bankAccount) will leak it

// using ECMAscript private
class Person {
  #ssn: string;
  constructor(ssn: string) {
    this.#ssn = ssn;
  }

  getLast4() {
    return this.#ssn.slice(-4);
  }
}

const p = new Person("123-45-6789");
p.#ssn; // ❌ Error

// using an opaque type
pub opaque type UserId {
  UserId(String)
}

pub fn user_id_from_string(s: String) -> UserId {
  UserId(s)
}

// callers can never see the inner String
pub fn user_id_to_string(id: UserId) -> String {
  let UserId(inner) = id
  inner
}

Invalid State Transitions

Invalid state transitions can be protected using types.

interface Doc {
  state: "draft" | "submitted" | "approved";
  // ...
}

function approve(doc: Doc) {
  // ⚠️ requires validation and test cases
  if (doc.state !== "submitted") throw new Error("Invalid state");
}

// ✅ Eliminates validation and test cases
// ---- States ----

export interface Draft {
  state: "draft";
  content: string;
}

export interface Submitted {
  state: "submitted";
  content: string;
  submittedAt: Date;
}

export interface Approved {
  state: "approved";
  content: string;
  approvedAt: Date;
}

// ---- Valid transitions ----

// Only a Draft can be submitted
export function submit(draft: Draft): Submitted;

// Only a Submitted can be approved
export function approve(submitted: Submitted): Approved;

// ❌ single type with a flag field
pub type Doc {
  Doc(state: DocState, content: String)
}

pub type DocState {
  DraftState
  SubmittedState
  ApprovedState
}

pub fn bad_approve(doc: Doc) -> Result(Doc, String) {
  case doc.state {
    SubmittedState -> Ok(Doc(ApprovedState, doc.content))
    _ -> Error("Invalid state")
  }
}

// ✅ Separate types for each state.
// A phantom type `Article(state)` could also be used.
pub type Draft {
  Draft(content: String)
}

pub type Submitted {
  Submitted(content: String, submitted_at: String)
}

pub type Approved {
  Approved(content: String, approved_at: String)
}

pub fn submit(draft: Draft, now: String) -> Submitted {
  let Draft(content) = draft
  Submitted(content, now)
}

pub fn approve(submitted: Submitted, now: String) -> Approved {
  let Submitted(content, _) = submitted
  Approved(content, now)
}

Design Review Checklist 📋

Rasmus Larsson — Mon, 17 Nov 2025 14:06:40 +0000

My simple checklist of things to ask as a developer when doing a design review in e.g. Figma.

Item	Description
Does it cover the happy case?
Does it cover the empty case?	E.g. if there are zero items in a list.
Does it cover the error case?	E.g. if fetching data failed.
Does it cover the growth case?	How do dynamic objects such as lists, text etc. grow beyond the fold or similar and how will the design react?
Does it cover the shrink case?	How do dynamic objects such as lists, text etc. shrink and how will the design react? What happens if a dropdown shrinks to just one item?
Does it cover not yet loaded/loading states?	Spinners, async states etc.
Is the flow clear?	Is the flow from view to view or between elements clear?
Does it cover responsive cases?
Does it cover accessibility?	E.g. left handedness
Does it show l10n/i18n variants?

Help I need a simple Kanban board!

Rasmus Larsson — Thu, 06 Feb 2025 09:16:26 +0000

Every now and again you're on a new project and need to setup a new Kanban board. What should you use? Trello? Jira? Something self hosted? Something freemium or even open source?

Here's a simple solution, use a text file.

$ touch TODO.md

### TODO

- look into X
- do some stuff

### DOING

- the one thing that will make everything else easier

### DONE

- pick a kanban board

Do you need to share it with other devs?

$ git commit -am "add a kanban board" TODO.md && git push

The day you find that you've outgrown this text file, pick a more advanced tool.

RabbitMQ Upgrade Best Practices

Rasmus Larsson — Wed, 29 May 2024 11:59:51 +0000

Some simple best practices around performing RabbitMQ upgrades.

Testing a New Version

Test the upgrade process.
Test the new version with your services/clients.
If doing rolling upgrades, test your services with a mixed cluster using the versions you will upgrade from/to.
Test rolling back.

Rolling Upgrade

Adjust according to your setup.

Per node checklist:

[ ] Assume roughly 5mins per node.
[ ] Ensure the node is not just visible in the dashboard, but also accessible via e.g. DNS names and similar.
[ ] Allow the cluster to stabilise with regards to replication, queue levels and similar.
[ ] Ensure the underlying (cloud) platform reports a steady state.
[ ] Ensure that clients can connect to the node and communicate.

⚠️ Rollback always takes longer than upgrade.

Release Windows

One release per window. If you need to do several upgrades, schedule several windows.

Naming Anti-patterns

Rasmus Larsson — Thu, 16 Feb 2023 11:07:36 +0000

Naming is hard

Smell	Why	Prefer
"Date"	Just "date" without a context does not help understanding when reading the code.	Prefer using a preposition together with some context such as "HappenedAt", "UpdatedOn", "AllowedAfter"
Just "in/out" or as prefix/suffix	These are easy to mix up but don't require a source/target which often results in ambiguity. Example: directories called `/files/in` and `/files/out`, this doesn't tell you in or out from where.	If you use "to/from", they require a source/target which should give more clarity. Example: `/files/from_remote_server` and `/files/to_remote_server`

Do you have any naming anti-patterns you'd like to share? Please do!

Credits:

Unsplash image

AWS Connectivity Troubleshooter

Rasmus Larsson — Thu, 09 Dec 2021 10:27:55 +0000

AWS Connectivity Troubleshooter

Just simple troubleshooting questions to ask myself whenever connectivity fails.

ECS <--> SecretsManager

Does the ECS task have network access to SecretsManager? e.g.:
- from a private subnet via a NAT Gateway or VPC Endpoint
- from a public subnet via a public IP address
Does the TaskExecutionRole have sufficient IAM rights to read the secret?

API Gateway HTTP API <--> VPC Link <--> ECS

Does the VPC Link have a security group that's allowed to access the ECS tasks on the given port?
Are the Cloud Map DNS records of type SRV?

RDS Access

Does the accessor have a security group that's allowed to access the DB?
Does the accessor have the right network access?
Is the accessor using the right port? (Aurora may set unexpected ports when using CloudFormation)
Have you double checked spelling?

Translation System Requirements

Rasmus Larsson — Mon, 23 Aug 2021 10:09:59 +0000

Thank you so much to @perty for this handy list.

Translations are editable by non-developers (and thus have a different deploy cycle than development work).
Obvious when translations are missing.
Obvious when a text is no longer in use anywhere.
Some locales have their own messages.
Some locales may not have all messages so no translation is needed for those messages.
There is a single source of truth, i.e. only one place for the translations.
Optionally, history of changes. Who and when changed a translation.
Fallback to a default language when translation is missing.
Contextual UI that shows the translator where the translation is used.
Translation suggestions based on prior work (within the project, but also using translation services)

Error Handling Responsibility Principles

Rasmus Larsson — Fri, 11 Dec 2020 08:20:26 +0000

Principle 1

The code closest to the source of the error is responsible for providing as much detail about the error and if possible classifying it if such is needed.

Motivation: The further you get from the error the harder this becomes.

Principle 2

Code further up in the call stack is responsible for deciding on how to act on the error given the current context.

Motivation: Called code has no idea of the context.

Example

A DB error is thrown. The code closest to the error classifies it as a socket time out. This is bubbled up in the call stack which then decides to not retry because a user has decided that the query is no longer relevant.

Special Note

These principles apply not only within an in-memory call stack but also across e.g. micro-service boundaries.

Do you disagree? I would love your input.

How To Analyze An Error

Rasmus Larsson — Thu, 07 May 2020 08:12:02 +0000

Dimension Checklist

Where - In which system, module, function and possibly line of code is the error occurring?
What - What is the actual error?
Who - Which actor/user is the error occurring for?
Why - Why is the error occurring?
When - When did the error occur?
Transient - Is the error still occurring?
Context - What is the surrounding context? Was something happening at the same time elsewhere that could be the cause? (deployment etc.)
Impact - What is the immediate but also long-term impact of the error?

Do you have other aspects of an error that you feel should be added to the list? Please comment. :)

Definition of Fatal, Error, Warn

Rasmus Larsson — Wed, 22 Jan 2020 14:39:39 +0000

Problem

Log and error levels are not always clearly defined making developers unsure of which level to use.

Solution

Define them explicitly. These are our definitions, you may have others.

Level	Definition	Examples
Fatal	An error that is so bad the service/system CANNOT perform any meaningful processing, and ideally should shut itself down (`Process.exit(1)`).	Misconfiguration of environment (wrong connection parameters etc.)
Error	An error that the system/service cannot recover from, but SHOULD NOT affect other processing.	Parsing errors, e.g. HTTP's "bad request".
Warn	An error that the system/service MAY recover from.	Retry loops, e.g. due to timeout.
Info	A non-error event in the system that is of interest to the business and/or operations.	Metrics, auditing, tracing etc.
Debug	A log point with high detail but of low value to normal business operation.	Used for understanding more about how the system is behaving.

Edit: added info and debug. Flipped the order around.

Feedback requested

If your definitions differ from ours I'm interested to hear about it. :)

Developer Handover Checklist

Rasmus Larsson — Tue, 13 Feb 2018 13:39:43 +0000

Every now and again you need to hand something over (code, thingamabobs, whatnot) to someone. At these times it can be good to have a checklist to go through. This is the list that I tend to use. All points are optional and users should strive for good enough. I've based it on architectural views as defined by Kruchten and others (C4 or some other scheme will work just as well).

Item	Description	Example
Business Case	An overview of the major business cases that motivate the existence of the solution.	Our customers must be able to make "claims" when they receive a defective gizmo from us.
Conceptual Model and Processes	Walkthrough of the conceptual model that is used in the solution. This includes the various business entities and the processes involved.	Entities: claim, receiver, product Processes: make a claim, close a claim, refute a claim
Functional/UC View	A walkthrough of the functional view and the use case view with one or two typical use cases and also the more complex use cases that need to be explained in more detail.	As a customer I can create a claim, list my claims, show claim etc.
Development View	Everything one needs to know to develop the thing: - components, modules - integrated systems map - information flow map - integrated dependencies (DBs) - development environment (tools, repository etc.) - environments (dev, test, prod) - deployment process (build chain, ci/cd etc.) - software/support systems used	Classic three tier architecture, MVC pattern in framework X. We also call out to the CRM system when doing ... Usually IntelliJ + git Wiki for documentation, JIRA for issue tracking.
Process View	A detailing of the execution model of the solution such as threading etc. with a concentration on the hard stuff.	The "GizmoService" is single threaded since it has to process the "GadgetJobs" in sequence and order must be maintained.
Physical View	A description of the physical environments available (should be correlated with environments in the development view) and what they contain.	Deployed to AWS EC2 instance, with ELB and CloudFront. Separate configuration for "test" and "prod".
Quality Requirements, Constraints	A description of the quality requirements and possible constraints and how they are achieved: - availability (SLA:s etc) - security - performance - reliability (fault tolerance, backup etc.) - configuration management - testability - licensing constraints - legal constraints
Operational View	A description of the operational view, how the day to day work goes, involved organizations and workflows, and how maintenance and support are performed.	We handle development and deployment but the "ops" team handles uptime, restarts, OS updates etc. Incidents come to us first and then handed over to ops if it's of a low-level nature...
Deliverables	Either an export of source code, docs etc, or access to SCM etc.	Code Contacts Documentation Scripts System accounts

Message History Pattern Revisited

Rasmus Larsson — Thu, 31 Aug 2017 09:58:03 +0000

We recently ran a book club on Enterprise Integration Patterns here at work.

One of the patterns detailed in the book is the Message History pattern (go read the pattern if you're unfamiliar with it). To give some context, let's start with a possible implementation of a message history.

Given the following pipes and filters setup:

[appA] -> [comp1] --msg1--> [comp2] --msg2--> [comp3] --msg3--> [appB]
                                         \--> [comp4] --msg4--> [appC]

----
app = application
comp = component
msg = message

A messageHistory header could have the following values in each step (using / as a separator):

Message	Value
msg1	`comp1`
msg2	`comp1/comp2`
msg3	`comp1/comp2/comp3`
msg4	`comp1/comp2/comp4`

For the sake of representation I've assumed that messageHistory is a simple additive string but it could be some other data structure such as a linked list or similar.

In a very long chain of components (or with long component names Ã la ERPProductUpdateAdapterService) this header may become prohibitively long for a message header. What then? Do we codify our component names as abbreviations or some other short but unique ID?

Another aspect is what happens with our tracing capabilities in a pub/sub scenario where we will have parallel messages fanning out with their own message histories in subsequent steps? One solution could be allowing a wild card search for comp1/* in some kind of tracking system. At least correlation between component logs and messages is fairly straight forward, but clearly we have to think carefully about our implementation so that we cover our various use cases. One of the major advantages is that you can get a complete overview of the message history by just looking at the message.

In the wild I have seen two other patterns that solve the same problem and are well worth describing, Message ID Chaining and Tracking ID.

Message ID Chaining

A unique reference ID is set in the header of each new message that points back to the previous message. This allows for collecting all reference points and building up an event chain. Optionally the field could also contain the component that generated the message.

Advantages:

Smaller header.
Possibly simpler to implement from a messaging viewpoint.

Disadvantages:

As mentioned in the book, what should an Aggregator that is combining several messages into one set?
A single message is no longer enough to get the big picture.
Requires some kind of tracking system to piece together and re-build the chain.

Tracking ID

A tracking ID (or tracing ID) is a unique identifier attached to the first message (or even before the first message) in a sequence of messages and then propagated along with all subsequent messages.

Advantages:

Smaller header.
Possibly simpler to implement from a messaging viewpoint.
Not inherently tied to a message and therefore more natural/easier to reference in other places such as logs, RPC calls and similar.

Disadvantages:

Does not contain component information, which must therefore be maintained in some other way.
Does not maintain sequence. Sequence must be maintained through some other means e.g. timestamp (which is susceptible to clock skew) or a sequence number of some sort.
Requires some kind of tracking system that can piece together events.

End Discussion

Are these two patterns actually patterns or simply variations of Message History? Hard to say. They definitely cover a common concern: tracing messages as they pass through message based systems. Regardless of your domain this is a powerful capability that can reduce maintenance and monitoring costs over time.

DEV Community: Rasmus Larsson

On Making Impossible States Impossible

Table of contents

Gentle Introduction

Patterns of Impossible States

Impossible Data Structures

Different Entity States/Sub-types with Different Field Requirements

Mutually Exclusive Fields

Mutually Inclusive Fields

Triple Value Boolean

Illegal (Boolean) Combinations

The Hidden Failure State

Constrained Values

Collections with Mandatory Values

Context Dependency

Constrained Value or Mutually Constrained Values

Private Data

Invalid State Transitions

Design Review Checklist 📋

Help I need a simple Kanban board!

RabbitMQ Upgrade Best Practices

Testing a New Version

Rolling Upgrade

Release Windows

Naming Anti-patterns

Naming is hard

AWS Connectivity Troubleshooter

AWS Connectivity Troubleshooter

ECS <--> SecretsManager

API Gateway HTTP API <--> VPC Link <--> ECS

RDS Access

Translation System Requirements

Error Handling Responsibility Principles

Principle 1

Principle 2

Example

Special Note

How To Analyze An Error

Dimension Checklist

Definition of Fatal, Error, Warn

Problem

Solution

Feedback requested

Developer Handover Checklist

Message History Pattern Revisited

Message ID Chaining

Tracking ID

End Discussion