Free your business growth with elastic software architecture

Some time ago I was doing research in regards to the way how start-up projects are managed from a technical perspective, and I found an often problem — how to scale an application in satisfying time frame, without cross-cutting changes in the codebase?

Common business scenario

Let’s imagine a typical business case. A company wants to validate business idea very quickly and with a limited budget. They develop something called a Minimum Viable Product (in fact in many start-up projects it is Proof of Concept rather than MVP) and launch it in a cloud. On the one hand, the company believes in idea success and wants to provide as many features as possible, on the other hand, project management is focused on quick launch. This opposite approaches usually exclude setting some time aside for a long-term strategy preparation of the project’s growth, which is a ticking time bomb that may blow off when you’re least expecting. If the code architecture is not well-thought, your project may end up in a state when you cannot develop anything new or implement a functionality change at a sustainable pace.

What are the symptoms pointing to architectural problems? Let’s see some examples.

• A simple improvement in the base code like changing the message text or updating configuration parameter requires launching the whole time-consuming release process.
• Understanding what is going on in the code takes a lot of time due to a massive amount of code in the single standalone code unit.
• Modules are tightly coupled, so it is a problem to make a change in one module without affecting the stability of the other dependant ones.
• Configuring a new development environment is a challenge.

If some of the above symptoms are true in your case, it’s time to think about architecture transformation. Depending on how far you planned the transformation strategy it will be a more or less painful process for the project.

Beginning shape of an application

Let’s try to review an application for meals ordering. A company is about to launch an MVP version of its mobile app that allows interacting 2 actors:

• Meal Providers upload their offers in the system
• Customers order meals.

The typical scenario is to prepare an easily extendable and deployable monolithic application as shown in the picture below:

Basic one-node architecture

At this stage, we need to think about potential bottlenecks that may stop business growth in the first place. So far it won’t be development speed, as the code base is relatively simple in the early phase. An entirely possible scenario is related to an increasing number of Providers submitting their offers to the system first before Consumers will start coming drastically and searching through offers. It may lead to overconsumption of IOPS in DB, so the first potential bottleneck is related to performance.

We can quite easily scale the whole application vertically by buying more resources in the cloud, but scaling horizontally may be a challenge. For example, you must take care of session data sharing between nodes, load balancing algorithm, etc.

Another thing that may affect scalability a lot is the decision whether to use RDBMS or NoSQL for data storing. Consideration of one or another approach is a good candidate for a next article, however, having an ability to use a NoSQL solution gives usually better built-in mechanisms for scalability. If NoSQL is impossible to use we need to consider an architecture that allows overcoming this problem with RDBMS.

Architecture growth

One of the fastest solutions that solve mentioned above problem is to separate reads from writes. The idea is inspired by the CQRS pattern, unfortunately, implementing this pattern is time-consuming. What we can implement quickly, is to multiply our architecture and combine it by introducing HTTP aware Load Balancer, which redirects reads (GET method) to one node and writes (POST, PUT, DELETE, etc.) to another. To reduce the amount of work, we should locate all components in one data center initially — load balancing between different DCs is a bigger challenge. The bottom line of the solution is that now we have 2 mirrored databases.

Two-nodes architecture with separated reads from writes

Conclusion

As you can see we scaled our app without the need of re-building the code base, which should be a quick job. This way we gained extra time for architecture refactoring and rethinking the whole tech perspective. In my next articles, I’ll try to show you what would be the next steps of a possible transformation.

Originally published at www.nexocode.com on March 20, 2019.

Want more from the Nexocode team? Follow us on Medium, Twitter, and LinkedIn. Want to make magic together? We’re hiring!