The Cancer pattern has a word we do not have a favorable view of.  However, this pattern is becoming needed in more and more environments.  This pattern is one for conversions and migrations.  We do not always have a clean slate for our architecture.  Thus, we need designs to handle the modification of an existing architecture.

The Cancer Pattern Defined

The way Cancer evolves is that it replaces cells with something new while leaving things functional.  This approach is how we often want to replace a system in place.  We cannot shut things down and might not be able to do a swap.  The cancer pattern is a sort of “hot swap” of a system with a new solution.  We do not address the entire thing at once.  Instead, we selectively update, upgrade, or replace pieces at a time.  As time goes on, we can entirely replace the system.  Sometimes without end-users being any the wiser.

Applying The Pattern

The key to this pattern is to isolate the pieces of the original architecture.  We want to avoid making more changes than needed.  Likewise, we do not want to de-stabilize the current system.  Think of a Jenga game where instead of removing blocks from the stack, you are replacing them.  When we replace a piece of the system, we want to make sure we do it in a way that mirrors existing integrations wherever possible.  You can review the microkernel pattern for another way that components are viewed as a plug-and-play approach to functionality.


Stability is the issue with this pattern.  When too much change is tackled in a batch, it can bring down the whole system.  There will also be integration details that can keep a component from being cleanly replaced.  Those situations can require some thinking layers or kludges to hold things together until we can craft a better replacement.  This pattern is also a time-consuming and complex one to implement.  You are not working from scratch.  Therefore, the original system needs to be understood in detail.  Then those details are used to map to the new solution.

Rob Broadhead

Rob is a founder of, and frequent contributor to, Develpreneur. This includes the Building Better Developers podcast. He is also a lifetime learner as a developer, designer, and manager of software solutions. Rob is the founder of RB Consulting and has managed to author a book about his family experiences and a few about becoming a better developer. In his free time, he stays busy raising five children (although they have grown into adults). When he has a chance to breathe, he is on the ice playing hockey to relax or working on his ballroom dance skills.

Leave a Reply