A Guide To Minimum Viable Architecture Points For Any Startup

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.

  1. Hypothesis- You want to get to market asap. All you want is things to work satisfactorily, not fail or show error and manage the incoming traffic, usually upto a couple of thousands.
  2. Growth- You get signs that your product is growing, traffic is increasing, and you want to build more features fast. Architecture expectations at this point would be about making things stable and secure. Have modularity to add more features and be able to manage workloads as well as monitor any surprises.
  3. Establishment- You now have tens of thousands of paying users. The company has layers of people, and a product roadmap is established not only for immediate use but also for upto 2-3 years. Architecture is now meant for managing.

Related Read:- How To Build A Scalable Video Streaming App Architecture?

Here is a summary of the various stages and the architectural needs:

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

  • Expected number of users at the launch?
  • Expected number of users in the first 6 months?
  • Expected number of users in a year?
  • A number of transactions expected per day, per hour, per second?
  • Any special requirements for compliance or security?
  • Any special requirements for availability, backup, and content type?
  • Any budgeting constraints on spending on hosting and infrastructure?

Here is a sample architecture for each phase of your product that you can use right away:

Architecture for MVP

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.

Architecture For MVP

Architecture for the growth stage

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 the growth stage

Architecture for Scale

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.

Architecture for Scale

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.

Microservice Architecture - Microservice Per Database

Microservice Architecture - Shared Database Model

Architecture can follow polyglot architecture when the architecture scales to microservices, as shown in the below diagram.

Polygot Architecture

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.

Common Architecture Needs

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.

minimum viable architecture for startup

coma

Conclusion

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.

Keep Reading

Keep Reading

Struggling with EHR integration? Learn about next-gen solutions in our upcoming webinar on Mar 6, at 11 AM EST.

Register Now

Let's create something together!