Intro
There are different factors that come into play when you want to scale a SAAS product. The application’s architecture plays a big role in this case. A good architecture allows the application to process traffic smoothly and faster. A good infrastructure empowers the application to run properly and be more responsive. Therefore, to scale a SAAS product, you need to investigate the application architecture and the infrastructure that hosts it.
A scalable SAAS is a product that can at any time, handle more traffic than the load it is currently serving and is also capable of adapting to the changing needs of its users. It automatically scales to accommodate dynamic traffic as traffic grows up and shrinks back down. A scalable SAAS also enables the manufacturer to smoothly extend it by adding, modifying or remove features.
Our MVP was built using a Monolithic Framework (WordPress – Drupal – Magento) and monolithic applications are limited as they are not designed to support high traffic load and they are not scalable. Therefore, they fail to meet the requirements of a scalable SAAS product. We need to make some changes if we want to target the big market of approximately 1 Million users.
How to Scale a SAAS Product
Looking at other design patterns, we notice that both SOA and Microservices are better approaches for building scalable products. One one hand, SOA is like an orchestra where each artist is performing with his/her instrument while the music director guides them all. Microservices on the other hand, is like a group of ballet dancers, each dancer is independent and knows what to do. If one of them misses a step or two, he knows how to get back on the sequence.
SOA is better suited for large and complex business application environments that require integration with many heterogeneous applications. Smaller applications are not a good fit for SOA.
Microservices are better suited for smaller and well-partitioned, web-based systems in which they give greater control to developers.
Here’s a picture to help you understand better the difference between Monolithic, SOA & Microservices.
So which one do we choose ?
Looking to penetrate bigger markets, why not! We can help you upgrade, we’ve done it before
Components and Interfaces
Both Microservices and SOA appear to be good design patterns for building scalable products and both are based on services. So before choosing which architecture to follow, let’s tackle see how we can transform our Monolithic application to offer services.
Begin by grouping all the features the product offers based on their logical and business value. Here, you are identifying your product’s components and the interfaces it has. For example, in the case of the Marketplace, the output will look like this:
Interfaces
An interface is a channel that your customers use to interact with your product. While doing the research, you should identify which interfaces your audience use and make sure your product supports these channels.
Web Interface
Enables users to use your product via a computer. It runs in a browser like Google Chrome or Firefox.
Mobile Interface
Gets installed on mobiles and tablets so users can use your product accordingly.
Admin Dashboard
This interface is restricted and can only be access by the administrator and the staff operators. It allows your team to operate on the product and support merchants and clients.
Components
Components represent smaller portions of your product; each component is a group of features that handle similar requests. Think of components as pieces of a puzzle. On its own, the piece doesn’t do anything and is pretty useless. Putting all pieces together, reveals a beautiful painting for example.
Members Area
Handles all requests related to the members area such as: Login – Logout- Register – Edit Profile …
This component offers the same functionality to both merchants and shoppers 💡 .
We only need to build it once and re-use it over and over.
This component should be multitenant.
Merchants Space
Allows merchants to provide their business information like: address – contact – POS – opening hours …
The functionality is the same to all merchants regardless of the data that merchants provide.
This component also needs to be multitenant 💡 .
Products Inventory & Catalog
Merchants sell similar products. A product might be priced differently depending on its variations (IPhone).
Products might be available in some Point of Sales and out of stock in others.
This component take care of how the product is stored in the database and how it should be display it in the catalog.
Order System
Processes shoppers orders, their payments and notifies the merchants about new orders.
An order can include products from different merchants, this components takes care of the details.
The order communicates with 3rd parties and with internal systems to make sure that the product being bought is still available and to process the payments.
Gateway
The Gateway is responsible for securing the product. It analyzes all the incoming requests, determines if they are eligible and identifies which microservice to forward the request to. It loads the settings from the database, adds them to the requests, then forwards the request.
This splits up the load in 2. The gateway checks and validates and the microservice processes the request. Think of this component as the steward who takes your reservation in a restaurant. He checks to see if you can enter and his list also tells him which table you should go to.
Wrapping it Up
To scale a SAAS Product, first we dissect the product features. Then we research which architecture patterns best suit our need. In the above use case, only the Order component needs to communicate with other systems. The remaining systems only need to check if the user is logged in before handling his requests. We therefore conclude that Microservices is a suitable design in this case. We can also conclude that by introducing the centralized API gateway at the beginning, we reduced the load that each system needs to execute thus speeding up the process.
The gateway also standardizes the communication between the microservices both internally and externally. The gateway acting as a middle man puts calm to the communication chaos. But isn’t that SOA architecture now ? Actually, it is, but stay with me, we’re almost there.
Next, we transform each of the above systems to a Microservice. Then, we deploy these microservices in the same network and only expose the gateway to the outside boundaries of this network. The gateway validates the incoming traffic and the microservices talk to each other using the internal network which by the way is fast.
Finally, let’s decouple the interfaces from the components and that too speeds up the application dramatically. The frontend no longer has to wait for the backend to execute so it can load and starts rendering. All the channels will communicate with the same microservices. We only need to define the contract of the APIs once. It will work the same way with all the interfaces.
By the time we’re done, our application is now distributed and scales partially as it needs to when traffic increases and decreases. The microservices inside it scale individually depending on which one of them needs to handle more traffic than it is currently serving. There is no need to scale the whole product, just a portion of it, similar to Pay as you GO.
Ok, so which design pattern won then ?
Our winner is …
BOTH!
Too much! Yeah we get that sometimes. Mike makes it sound so simple, let him help
Summary
As you can see, a product of this magnitude offers amazing challenges and many issues that should be resolved. If done right, it can provide an immense experience to both shoppers and merchants. We redesigned our application by analyzing its components and upgraded the architecture that is should use.
This new architecture allows our product to serve more traffic and faster. As more requests arrive, you only need to scale the components that are affected.
We also concluded that no single design pattern can suffice to build a scalable product. By using both SOA and Microservices, our product is more mature and elastic. It scales as it should and it’s very smooth to extend its functionality and capabilities.
Remember, a scalable SAAS is a product that can at any time, handle more traffic than the load it is currently serving and is also capable of adapting to the changing needs of its users.
online pharmacy
I believe this is one of the most vital info for me.
And i am happy reading your article. But want to remark on few common issues, The website taste
is ideal, the articles is really excellent :
D. Just right process, cheers