The architecture of responsive and scalable product for Startups.

Startup Companies

New emerging companies that build innovative product often call themselves as a Startup. Creating an innovative product is a risky strategy. Almost all products in the current digital world actually are software products. At least digital technology is an integral part of the product. Startup team tries to find own market niche. During that period the team tries a range of hypothesis about user's needs and expectations. Every assumption is verified on the real user base. Changing the business model of the new company calls pivot. Every pivot might have a different range of product features. Once the startup has found the working business model, the team scales the product as fast as possible. Filling the market niche is often critical for the business. Blue ocean couldn't be during a long period of time. The fastest company could become a market leader in that niche. Inability to scale the product is a significant bottleneck for the startup. Fortunately, that is only the technical perspective. The right system architecture solves software product scaling limitations for the Startup.

Software Product Scaling

Product scaling is the support of a growing amount of active users. The ability to scale from hundreds to thousands or even millions of users is a significant market advantage of the Startup team. Designing the system for 100 users and for 1 Million users are quite different architectural problems. Scaling up means handling a higher amount of users than in the past. Additional hardware is required for serving additional active users. Certain software services are experiencing peak load during holidays or specific events. After these events, active users amount decreases and scaling down is required. Keeping hardware utilization at that level leads to not necessary expenses. The system designed for a small number of users can't be scaled just by adding new hardware. Rethinking and redesigning architecture could be not an easy task for the Startup. Startups team doesn't have time to redesign the system. The delay in releasing new product feature closes a market opportunity. The system that could scale up and scale down often called as Elastic System.

Reactive Systems

Scaling is not the primary goal in the system architecture of the innovative product. In the big multiuser system responsiveness is the key value. That means the system is responsive in a timely manner despite the failures in parts of the system. Users have the same smooth experience during different system load or failures of the components. The system could disable a range of features depends on what parts are unavailable. But the whole system is working and is responsive. Resilience is the system property to work gracefully with failures. Components isolation, parts replication, and other technics make system resilient. The responsiveness goal is reached by message-driven architecture, elasticity, and resilience. The kind of systems, that startups would like to build, is described in Reactive Manifesto. This document was created because many companies were solving the same described here problems. This document defines the core principles for building responsive systems.

The Reactive Manifesto signed by me 5 years ago:

Actor Model

There is a range of technologies that give the ability to create a system based on reactive principles.

Actor model (from https://en.wikipedia.org/wiki/Actor_model):

Core abstraction in this model is an Actor. It encapsulates certain actions of the business domain. Important point is that Actors are not communicated with each other directly. Actor Model assumes that communication between Actors is asynchronous and non-blocking. Absents of direct actors dependency to each other gives the ability to scale the application. Depended Actor could be located in different application node. For the application location of the Actor has no matter.

Akka framework is built on Actor Model. Akka is created in mind with principles of Reactive Systems. Supervision strategy is the way for the handling of failures. Supervision means that external Actor is responsible for Actor failure resolution. Because failed Actor doesn't have enough abilities to handle it gracefully. Not working system component shouldn't recover itself, the only external arbiter can do it elegantly.

Scala and Java could be used for building Reactive Systems. Frameworks like Akka make the creation of Reactive Systems much simpler. The properties like failure resolution, location transparency, service discovery are provided by this framework. To implement the Reactive System these properties for sure should be implemented in certain technology. No way to build Reactive System without implementation of these properties. Mature frameworks like Akka could help save time and effort during building Reactive System. Scala could be used for asynchronous and non-blocking programming. Complex asynchronous logic in Scala looks quite concisely and gracefully.

Reactive Programming and Reactive Systems

Building the system on the Reactive programming principles doesn't mean to build the Reactive System. Reactive programming could be used for Reactive System building but it is not enough. Reactive System should have replication of responsibilities and least several nodes for handling Failures. Infrastructure technologies like Kubernetes could help in managing microservices of the Reactive System.

Conclusions

Building the system on Reactive System principles could help Startup team to save effort and money by creating the product that scales. Scaling could be cost-effective with the right technology. Recreation the application on another architecture is a time-consuming task. Designing a responsive system for a high amount of active users is a complicated task. Only the right tools could help achieve this goal on time and take advantage in the market.

Use the right tool for your architectural challenges and you meet your goals.

Cover photo by Christian EM on Unsplash