Hi ,

I have been reading the book Fundamentals of Software Architecture by Mark Richards and Neal Ford over the holidays. It contains lots of useful information for architects or aspiring architects.

The authors defines some rules for software architecture. The first one is: "Everything in software architecture is a tradeoff".

There are no "perfect" architecture, there will always be tradeoffs. As architects we can always answer questions about architecture with "it depends".

The choice of architecture depends on the needs of the business. It should evolve and change as the requirements change.

It's a big difference between building an enterprise application with constant changing requirements that should be in use for several years and a tool that should process some data in the fastest possible way.

Sometimes we have to trade performance for maintainability and simplicity and other times we have to do the opposite.

A good example of this is a challenge posted by Java champion Gunnar Morling. The goal is to use Java 21 to process a text file with 1 billion lines of data in the shortest possible time.

The top submissions are linked and available for everyone to see. This gives us an opportunity to compare different solutions to a specific problem.

The baseline implementation takes over 4 minutes to complete while the current fastest one completes in just under 15s.

The faster implementations have made more tradeoffs on readability and simplicity to get better performance. This makes sense since this is a challenge to make the fastest implementation after all.

However, this is usually not the case when we are designing systems. The performance has to be "good enough". We can trade some performance to build software that are simpler and easier to modify.

We should always try to understand what the performance requirements are when we are designing software. It will impact the tradeoffs we are forced to make.

If there is a performance problem in your application. Make sure to measure both before and after optimizing. We only want to add complexity where it's actually needed.

The challenge is open until January 31 and more information about it can be found here: https://github.com/gunnarmorling/1brc

Enjoy,

Markus Westergren