There’s a term in drawing called “negative space”. The idea is very simple: you don’t draw what’s there – you draw what’s not there.

Credit: http://www.artinstructionblog.com/an-introduction-to-negative-drawing-with-mike-sibley

NEGATIVE SPACE by Leonardo Santamaria for Satellite Citi.

In software architecture realm, we usually come up with a basic design, implement a “layout” (infrastructure of your application) and then start augmenting it by adding features and providing better coverage for different use-cases.

Defining the negative space of your program means that not only you define what it should do – but also declare what it shouldn’t. By understanding what should be the limitations of your program you can simplify the design and easily reject feature requests that are crossing these borders.

In the world or micro-services it is very easy to create a new service and sometimes the right decision is to not support a new capability in “service A” but rather push that capability into a more qualifying “service B” or even spawn up a new dedicated service.

During my work at Netflix I ran a few times into a case where we needed to implement a new capability into existing services. That capability had a complex spec and was latency-sensitive, so we created new services in order to be able to:

1. Keep the current services simple
2. Add a new dedicated caching layer, but more important:
3. Make our services resilient by applying the bulkhead design pattern.

So next time you architect a piece of software don’t forget to take into account the negative space!