The Boring Architecture

There exists a concept called "Boring Business" in the business world which is there since long and is there to stay. It's features are :- it is robust, very little scope for innovation & creativity is required to improve but it will give you profit no matter what. Something similar is there in tech world also. That is "The Boring Architecture". In most of the conferences you will find numerous talks on Complex arch. but none on the simple arch. It provides effectiveness at another level still people go for complex arch for their small solutions also. Let's check it out :-

As the initial step you can use the tools provided by vendors instead of building all the tools in-house with coffee competencies. So there will be few blockers in the way, some of them are :-

• You may find bugs in the tool and it will be difficult to convince the vendor the work on the bug.

• You may be looking out for some features whereas tools with those features may not exist at all.

• Most of the times you will many features with a complete package of the tools, it of those you won't be using all but will be paying for all

• In case you want a specific feature in a specific tool then it will be very hard to convince the vendor to add it. It may sound simple but actually it has many consequences. After listening to you if the vendor adds that feature, it may work wonders for you but for the other customers it may come out as a boon

Apart from the tools, let's say if we start designing the arch, they language we will choose is gonna take a crucial role in the whole journey so it should have concurrency support (python, go), performance, extensive dynamism. It's downside should so let's that the cost of extra maintenance should be less instead of migrating to a new tech stack.

• The API should be GraphQL because of its numerous advantages and very less cons. This would really help while scaling app too.

• RabbitMQ or Redis will work well for the message queue purpose. No need to go for the other alternatives present out there.

• In case of protocols you can use custom protocols with UDP, USSD or HTTP/3 also.

• One of the advantages of boring arch is when you expand, you have to break the backend into parts and deploy it as per the rules and regulations of the particular country where you will be operating. So for this kind of host management purpose Kubernetes will be the best choice.

Thanks for reading upto here 😇

Resources

• infoq blog

• wave engineer blog