When designing large, complex systems, you try to break things down into manageable chunks. For example, the bit that deals with user login or authentication. The payment bit. Something that needs to happen periodically. That sort of thing.

Before you know it, there are tens, or hundreds of chunks, each talking to each other or getting triggered when something happens. Problem is, how do these bits share data with each other. You can copy all the data between each chunk, but that’s not very time efficient. And if something goes wrong, you end up with a mess of inconsistent data everywhere.

So what bits of data do you keep in a shared place? What gets copied around from place to place? And what gets only used for that one function to get the job done? This is the job of software architects to sort out.

The author says the more copies of something you make, the more complexity and ‘state’ management you have to deal with. He’s right, but there are ways to mitigate the problem.