Author Archives: Jimmy Bogard

About Jimmy Bogard

I'm a technical architect with Headspring in Austin, TX. I focus on DDD, distributed systems, and any other acronym-centric design/architecture/methodology. I created AutoMapper and am a co-author of the ASP.NET MVC in Action books.

Strategies for isolating the database in tests

One of the keys to having maintainable tests are to make sure that tests are isolated and reproducible. For unit tests, this is easy as long as we stay away from global variables, static classes and in general global state. … Continue reading 

Posted in Testing | 15 Comments

Distributed systems reading list

Something I wish I had read years ago (or found out about) is this nice concise list of resources around distributed systems: http://dancres.org/reading_list.html When I started having issues around 2PC, and twitter was being beyond unhelpful with pointers to actual … Continue reading 

Posted in Distributed Systems | 2 Comments

ACID 2.0 in action

One of the comments in my last post on message idempotency asked about message ordering. This is part of a larger issue that I’ve run into recently around turning two-phase commits off. When looking at mutating state through interactions, typically … Continue reading 

Posted in Messaging, SOA | 5 Comments

(Un) Reliability in messaging: idempotency and de-duplication

In my post on ditching two-phase commits, I introduced the problem of trying to listen and talk at the same time. Essentially, people typically do two-phased commits in messaging systems because they want to deal with messages “exactly once”. But … Continue reading 

Posted in Messaging, SOA | 7 Comments

Eventual consistency in REST APIs

Not picking on an API in particular, but…wait, yes I am. Octopus (an awesome product) has a proposed API on GitHub, and one of the things it describes is how to deal with the fact that the backend is built … Continue reading 

Posted in REST | 11 Comments

Saga patterns: wrap up

Posts in this series: Observer pattern Controller pattern Pattern variations Scaling sagas Routing slips NServiceBus sagas are a simple yet flexible tool to achieve a variety of end goals. Whether it’s orchestration, choreography, business activity monitoring, or just other long-running … Continue reading 

Posted in Messaging, NServiceBus | 3 Comments

Ditching two-phased commits

I’ve had a love-hate relationship with two-phased commits during my years with messaging. Even if MSDTC was free to set up, it doesn’t come free in terms of throughput. Most people run into 2PC in messaging because because queueing systems … Continue reading 

Posted in Messaging, SOA | 17 Comments

Messages, data and types

One concern I receive quite a bit from folks new to messaging, especially those coming from SOAP and WCF land, is how to preserve the convenience of proxy classes and data contracts that can be shared amongst multiple clients. The … Continue reading 

Posted in Messaging, SOA | 7 Comments

Saga alternatives – routing slips

In the last few posts on sagas, we looked at a variety of patterns of modeling long-running business transactions. However, the general problem of message routing doesn’t always require a central point of control, such as is provided with the … Continue reading 

Posted in Messaging, NServiceBus | 3 Comments

Scaling NServiceBus Sagas

When looking at NServiceBus sagas (process managers), especially at high volume of messages, we often run into two main problems: Deadlocks Starvation This is because of the fundamental (default) design of sagas is that: A single saga shares a single … Continue reading 

Posted in Messaging, NServiceBus, SOA | 7 Comments