Building an MVP? Once you have decided all the features that go into it, the important decision remains about your technology and architecture. Architecture is the glue that holds all of your technology decisions together; hence, it is important to take a cautious step towards getting your architecture right.
No time to read the full blog? Here is a video on Minimum Viable Architecture that you can check out!
So what should drive your architectural decisions? There can be many reasons that define your architecture, but primarily it would be about what you want and expect from your product.
A product usually has 3 stages in its journey.
Related Read:- How To Build A Scalable Video Streaming App Architecture?
Here is a summary of the various stages and the architectural needs:
Now that you have understood at a high level, here are some questions that can help you make your decision
Here is a sample architecture for each phase of your product that you can use right away:
This is the stage for “Bare minimum architecture.” The focus will be to put together a bare-bone basics setup. By keeping architecture minimal, you truly marry the minimum viable product development approach. You can focus on speed and also save costs.
Here is what we recommend
Architecture can start with base features and move to alpha and beta releases.
Alpha Release – This is when the feature you are developing is incomplete or partially complete. Suppose you have developed the cart creation in an online ordering system, but the payment implementation remains. In this case, you can release it to testers to test the initial phase of the feature. A lot of Open source products do their Alpha release.
Beta Release – This release is done when the product feature is complete and all the development is done, but there are possibilities that it could contain some bugs and performance issues. This release is mostly done for users who test the product and who can report the bugs. Even the UAT (User Acceptance Testing) phase could be considered a Beta release.
This is the stage for “Foundational architecture.” The focus is to start doing things the right way but still not bother too much about scale. As users evolve, new features must be created, hence, the need for modularity and different layers for data and presentation.
The architecture should follow loosely coupled and high cohesive modular architecture. Features are released on a need and periodic basis. Features are tested with various strategies like canary deployments and blue-green deployments.
Architecture for scale is the stage for “Proper Scalable architecture.” The focus is on creating efficiencies and scale. You have to think about load balancing, concurrency, availability, etc.
Remember- “If you don’t regret your early technology decisions, you probably over-engineered……Rearchitecting is a sign of success; if you never need to, either you overbuilt or nobody cares.”
Architecture can start from monolithic and enhance to microservices.
The architecture can go with on-prem, single cloud, hybrid architecture, multi-cloud or poly
cloud architecture.
The decision will be based on the cost factor, operational efficiency, cloud PaaS and
Managed services.
On-prem: The compute and data layers are in the on-prem own data center.
Pros: More security
Cons: High operational cost, complex setup in auto-scaling
Single Cloud: The compute, and data layers are hosted in the cloud of a single cloud
the provider(either AWS/GCP/Azure).
Pros: High operational efficiency, Effective auto scaling
Cons: Tight coupling with a single cloud provider
Hybrid: Few services in the cloud and few on-prem.
Pros: Balance of system features usage between cloud and on-prem
Cons: Latency issues when connecting between on-prem and cloud
Poly or Multi-Cloud: Balance of cloud services leveraging between various cloud providers
Pros: There might be some services provided with good features by one cloud provider
and some other features by some other cloud providers, the balance of features will be
possible when we leverage multi or poly cloud
Example: AI services are good in GCP, and the data stack is good in AWS/Azure.
An architecture can be built leveraging both cloud services based on the requirement.
Depending on project needs, microservices can follow a shared database or database per service model.
Architecture can follow polyglot architecture when the architecture scales to microservices, as shown in the below diagram.
Other common architecture needs are worth mentioning.
1. Architecture for Partner Integration
When the architecture starts from MVP and scales to a certain level, partner integrations should have scope to make a full-fledged product engineering area.
2. Architecture for process
Architecture should follow the process aligned to the organization’s standards while not deviating from the non-functional and functional requirements.
3. Architecture for Visibility
Architecture should have a clear vision either for MVP or for architecture for scale. Vision should also be properly set with standards and documented.
4. The architecture is defined with visualization.
Visual representation of architecture will properly articulate and provide a clear goal of the MVP at scale.
Companies have different architectures created all the time. Consider the example of Twitter.
Twitter started with a content management platform and slowly evolved to a messaging platform with several optimization approaches in caching, message queue and cache client.
The evolution of the architecture started with the initial tech stack, followed by proper optimization and scaling methods and decisions to change the tech stack and implement these with proper evolution methods.
The cache optimization started with write through vector cache for tweets id’s followed by write through row cache with users and records.
The MQ optimization started from MVP to highly scalable components.
The first implementation of the MQ was using Starling, written in Ruby, and did not scale well, especially because Ruby’s GC is not generational. That led to MQ crashes because, at some point, the entire queue processing stopped for the GC to finish its job. A decision was made to port the MQ to Scala, which uses the more mature JVM GC.
The Memcached client optimization was intended to optimize cluster load.
Hence, don’t be afraid. Do not overdo it.
Get the right architecture for your need and keep building on top of it.
Building A Healthcare MVP? This Video Might Help:
Here is an infographic that can help you to understand the minimum viable architecture.
In this blog, we have tried to explain the basics of MVP and how to achieve it. We also tried to showcase how you can develop an MVP based on the functionalities you need and the changes you want to see in the marketplace. One important thing to remember while building an MVP is to plan and develop your MVP in a manner that can help you adapt to the changes in the market and make the most of your product.