The architecture of your software system have a big impact in multiple aspects of your project, from its scalability and resilience, to the cost of operating it, to the ability of your team to change it.

A lot of different aspects of your project must be taken into consideration when (re)designing the architecture of your system.

How big is your team?

While a smaller team will easily manage to work together in a monolith without major conflicts, and can, generally, coordinate changes to avoid conflicts, as the team grows, it becomes important to create contracts between the team - apis and data streams are the two most common ways to define those contracts.

Realtime vs Delayed

How important is the latency of your requests in your system? When your client makes a request is it important to process it immediately or can it be done a bit later? How much later? A few milliseconds? A few seconds? Several minutes? Next day?

For most systems a mix of both is the best choice, but what needs to be done synchronously and what can be postponed is not always obvious. And how do you postpone it? A asynchronous task? A message queue? A pubsub system?

Options, options, options. And quite often choosing the best technology is not the most important factor - choosing a technology that plays nicely with your team and your ecosystem - the programming language, the databases, the cloud system, etc - can be equally important.

Monolith vs Macro Services vs Micro Services vs …

What serves Netflix and Uber may not be the best option for your team. While they have the people and money to invest in the needed infrastructure and know how to handle a system with more independently deployable components than the developer writing the code of those component, do you?

Can you team handle the cascading failures that micro service based systems are prone to have? Does your team have the time and know how to setup mesh networking systems and circuit breakers to prevent them?

How much downtime can you business live with?

In 1998 I helped setup a couple of Disco setups. Disco was a bar/disco POS system. The most interesting feature of Disco, for me, was that it used a client/server architecture, but the clients could work independently of the server being up.

A normal setup of Disco would have a bunch of computers (one in each bar), each with their own UPS (battery), a central server where ultimately all data was stored, which kept track of inventory and all of that, but if the server was down, the POS computer would keep registering sales, printing notes, getting money from their clients.

Generally, they didn’t care if the inventory was gone because if the bartender was able to sell it was because there was some to sell. When, eventually, the server come up and the POS was able to connect to it, it would upload the sales, get updates on prices, etc.

Today we build a lot of system that assume that internet is fast and reliable and that the server will always be there. Can your business work with such assumptions?

Times change

And everything else changes with time. When you system was started some assumption were made about how your business would work. As time passes, some of those assumption are proven right, some need to be adjusted. How implications does that have on your system?

And how can you transform the system that served your business so well so far into the system your business needs today? Into the system that your business will need to travel the road ahead?

And how do you change it while your clients keep coming in, while you keep serving them?

I can Help

I have plenty of experience rebuilding systems while they keep running, with minor disruptions.

I can help you team (re)design and (re)build your system in line with your needs, while your business keeps flying always slightly higher, always slightly faster.