For Startups to be successful, they need to ensure that the minimum viable products (MVPs) they
are developing are innovative and able to scale to meet user demand and future growth.
Understanding the transactional requirements of an MVP based on actual use cases helps
Startups break away from a monolithic approach to product development in which adding new
functionality requires a full release that may not be capable of successfully scaling to meet real-
world demands.
A monolithic approach to application development makes deploying a product risk-prone. Product
deployment usually causes downtime. If an error occurs in any module, the entire application is
affected. New libraries may not be compatible with versions of the application.
As the number of users increases, the application may perform poorly because it cannot
accommodate increased transactional demands. Adding more users can cause inconsistencies in
response times that negatively impact performance. Increased traffic can block access to the
application and cause data loss. Error detection becomes difficult, and troubleshooting gets more
complex if logging happens on the server.
Breaking the monolith using Amazon API Gateway, AWS Lambda, and Amazon DynamoDB
enables Startups to hyperscale for more successful and profitable product launches based on
realistic performance expectations.
Getting away from the monolithic approach to product development means dividing application
functionality into independent feature-specific components. The Startup can take a variety of
strategies for dividing up the monolith, such as by business capability or type of transaction. Each
component must be both independent of and loosely coupled with the others.
Solution and Application Architects usually use Software Engineering approaches like Model-
Driven Architecture – defined by the Object Management Group [1] - to break down the monolith in
a microservices architecture, for example. However, I recommend focusing on the use cases from
the user point of view that will cause a significant volume of transactions for software-intensive
systems. A suitable Software Engineering mechanism to achieve this approach is the “4+1” View
Model of Software architecture, defined by Philippe Kruchten [2]. With the 4+1 View Model, the
Software Engineer models the system based on multiple concurrent views. Each view will be the
interface of the interaction of various end-users. A view represents an end-to-end use case – a
distributed transaction in modern applications.
Looking at a specific use case of a mobile driving application helps to illustrate how breaking the
monolith can help a product scale successfully. Using Amazon API Gateway to access data,
business logic, and functionality, a Startup can understand how users of a mobile driving app
access data and behave during trips.
Not all transactions are identical, so understanding how transactions access data is the best way
to scale. In the use case of the mobile driving application, trip events generate data related to user
driving behavior.
To scale successfully, a Startup needs to decide which metrics to track based on what’s essential
to the business. Metrics help companies understand how they need to adapt to scale.
To analyze throughput, a company should start with assumptions about the amount of throughput
per transaction and the rate of increase in transactions.
For the mobile driving application, the company may predict adding 1,000 new users a month, with
an average of 4 trips per day, an average trip duration of 10 minutes, and an average of 600
events per trip. At that rate, 72 million transactions would require a throughput of 28 seconds. The
Startup will need to find a way to manage data more efficiently to handle this level of growth.
When analyzing data access patterns for the mobile driving application, companies should focus
more on writes than reads transactions. Other applications may need more reads, such as e-
commerce sites where catalog searches outnumber purchases. Companies need a way to
separate writes from reads and get them to a database to record and review the data. This way,
they can tell where time is spent in a transaction.
In the case of the mobile driving application, drivers usually do not use their mobile to check trip
data during the trip. Typically, users review their trip data minutes after a trip ends. Users get
weekly or monthly driving reports. Data reconciliation may be needed after a trip instead of in real-
time.
A trip event with the same ID and timestamp will replace an existing one with the same data. Trip
events must be ordered by timestamp for a given trip.
Analyzing data access patterns and transaction times shows how spikes in traffic may cause
database transaction management issues.
Scaling with microbatches optimizes throughput for transactions. Microbatches optimize resources
so the same information can be sent in fewer transactions. Records can be inserted into the
database in bulk, requiring fewer roundtrips to the database. Microbatches make a solution less
expensive, creating the opportunity to increase the Startup’s profit margins.
With load testing, projected growth and costs are easy to estimate. Load testing with a defined
number of users will help the company predict the solution's scalability. This way, the application
can achieve linear, logarithmic, or exponential scalability, depending on computational complexity.
Companies can predict projected growth for many users so they know how to meet capacity for
resource needs and costs.
For the driving application, a calculator can be put together for plugging in numbers of users and
assumptions, such as trips per user per day and average trip duration. The calculator can create
package pricing so the Startup can price a cloud-native solution.
When applications are launched, they can experience unpredictable peaks in traffic. The
application needs to react. To scale effectively, Startups should know how much they spend per
transaction, not per subscription.
Your company needs to carry out a proper analysis to scale software. At IO Connect Services, we
can set up a demo for load testing. As an AWS Advanced Consulting Partner, we can help you
hyperscale using Amazon API Gateway and DynamoDB.
Amazon API Gateway is used for creating, publishing, maintaining, monitoring, and securing REST
and WebSocket APIs at any scale. With Amazon API Gateway, developers can create APIs for
use in their client applications or make Web APIs available to third-party app developers. Amazon
API Gateway provides developers with a secure and highly configurable entry point to other
resources and applications inside AWS or other platforms.
Using MuleSoft? Learn more about how to leverage Amazon API Gateway.
When DynamoDB is a No-SQL database, the solution keeps writing and reading times constant. It
keeps the schema flexibility of the data stored, allowing some premium clients to use different data
models. The consistency provided by DynamoDB is a crucial factor in designing asynchronous
transactions that help scale volume substantially.
Find out how hyperscaling with AWS can help your company launch successful applications.
Schedule a free consultation with IO Connect.
References:
