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:
