Architecture Body of Knowledge

Performance

While software architecture has always been an exciting topic for me, I often saw a conflict of interest between performance concerns and architecture. With more mature technology choices and architectural styles for selection, now I have better answers for those who worry about performance while architecting solutions.

Performance vs. clean design

When we write code, there are many times when performance and clean design become competing factors. For example, batch data retrieval and processing might finish faster than processing a single item at a time although the latter arguably results in cleaner code. Which way should you go?

I feel that with so many ways to scale application, questions like the above become simpler to answer. You would go with single item processing and scale components that are responsible for executing work. With a sufficiently sizable horizontal scale, single item processing will be at least as fast as batch processing.

Therefore, do not sacrifice a clear design for performance; instead, find architectural alternatives for solving performance issues. Do not declare loss without consciously understanding all your options, as that is a typical scenario that I often witness.

Let me clarify; performance is an important topic, and you should not ignore it. Instead, you should find a proper compromise between performance and architecture.

Designing components that need to be fast

The previous section addressed decisions between performance and clean code. Sometimes, a given component needs to be fast, irrespective of how its design looks. In that case, separate critical algorithms from the domain layer via abstraction (i.e., interface) and optimize the extracted code block. Remember that most optimal code is not readable, and it should not get into the way of business logic.

Such components must be an exception from the earlier described rule, which suggested that a horizontal scale should address most issues.