Immutability in Message Types

In just about every custom I've worked with, eventually the topic of immutability in messages comes up. Messages are immutable in concept, that is, we shouldn't change them (except in the case of document messages). Since messages are generally immutable in concept, why not make them immutable in our applications dealing with the messages themselves? Immutabilty has a number of benefits, ask Mark Seemann laid out in a discussion question [Read More]

Message Naming Conventions

One of the first design decisions teams starting with messaging are presented with are - what the heck do we name these things? When building out request/response types for typical API/web applications, I name the responses usually after the resource they represent, or the route, or controller/action. There's something already "around" my message that tells me what to name it. Durable messages are a bit different - [Read More]

Composite UIs for Microservices: Vertical Slice APIs

This is a recent follow-up pattern to my series on Composite UIs in Microservices, which explores various strategies for composing at the edges. Other posts in this series: A primer Composition options Client composition Server composition Data composition Vertical Slice APIs When looking at a client-side composition, the next logical question is "how do my client-side components communicate with services?". Typically, there are two main approaches: API Gateway Backend-for-frontend In [Read More]

Life Beyond Distributed Transactions: An Apostate's Implementation - Conclusion

Posts in this series: A Primer Document Coordination Document Example Dispatching Example Failures and Retries Failure Recovery Sagas Relational Resources Conclusion We started out with a common, but nearly always overlooked problem: how do we reliably coordinate activities between different transactional resources? The question we need to ask first is - do we need to coordinate these activities? Ultimately, it's a business decision about how to deal with the messiness [Read More]

Life Beyond Distributed Transactions: An Apostate's Implementation - Relational Resources

Posts in this series: A Primer Document Coordination Document Example Dispatching Example Failures and Retries Failure Recovery Sagas Relational Resources Conclusion Sample code from this series So far in this series we've mainly concerned ourselves with a single resource that can't support distributed (or multi-entity) transactions. While that is becoming less common as NoSQL options, as Azure CosmosDB supports them, and with the 4.0 release, MongoDB now supports multi-document [Read More]