Serverless Architecture

The following post is part of a series of articles chronicling my journey into serverless implementation via a sample Case Study using a minimal viable product (MVP). TL; DR the source code used for the implementation and instructions on how to run the app locally are on GitHub.

Since I am planning to use Azure Services for serverless implementation, the overall components and system architecture for the product looks as follows:

The application is composed of three layers.

The Business Layer

1. The business layer is responsible for processing requests that are coming into the application via function triggers and passing data to the persistence layer as needed.
2. The business layer includes
3. - An Orchestration Function
   - Orchestrator triggered durable functions
   - A hook to Twilio API to send text messages

[More on Business Layer]

The Data Layer

1. The data layer is responsible for storing data that is coming from the business layer and also fetching records that are stored in the storage.

[More on Data Layer]

The Presentation Layer

1. I have used the word “Presentation Layer” loosely to group together elements of the architecture that are responsible for communicating with end-users. The communication between the business layer and presentation layer is event-based (i.e. a user sending a text (an event) triggers a data processing in the business layer). Roku devices will poll API endpoints to access parts of the business layer.

[More on Presentation Layer]