Event Driven and Stateless Architectures

Technologies evolve and new patterns replace the old way of doing things. In the early days of the internet, there was no concept of state, every request to a web server responded with a resource like HTML and other resources. The user experience of the website was improved by designing persistence mechanisms such as sessions via cookies, disk, or memory. The web has evolved a lot since then. We have modernized web apps and we have open standards and a big ecosystem to create applications. Newer applications make use of the Representational State Transfer architectural style to create Restful web applications that use the HTTP protocol to transfer requests for web resources. In the following sections, we will understand the difference between stateful and stateless with several implementation reference architectures.

In this chapter, we...

Technical requirements

There are no technical requirements for this chapter.

Web application hosting

The three tier is a common architecture for web applications. This architecture is designed to be highly scalable by providing the web tier, which is responsible for the incoming requests from the Elastic Load Balancer. They act as a proxy layer, then these requests are propagated to the middleware tier.

Route 53

DNS requests are solved by Route 53 (1) answering with a CloudFront distribution (2) with origin on S3 (3) for static assets and an ELB for dynamic data (4). The best practice is to offload all static data to S3 buckets by removing servers the responsibility to manage data. This decouples other layers (5) and provides maximum flexibility when resources are created or terminated by Auto Scaling...

Serverless application architecture

Serverless models are designed to be very efficient and cost-effective. They provide a high level of abstraction over the computing layer and they are 100% designed to be stateless.

The stateless design principle consists of offloading all persistence out of the compute service, in the following diagram several persistence services are used, such as Amazon S3, Amazon ElasticSearch, and DynamoDB.

This architecture represents a voting platform with a real-time dashboard that presents voting results in real time. Every vote is done via a mobile app. When the user votes, this event triggers an API gateway service endpoint invoking a custom resource like POST /votes/candidate.

When this vote is received by the API gateway resource an integration is executed, for this case is a Lambda function that provides the logic to increment the valid_votes table...

Streaming data architecture

AWS Kinesis is a scalable streaming service that can be used to ingest data and is fully managed. The ingestion can be done via the Kinesis Client Library or the Kinesis Streams API (1), in both cases data is durably stored up to 24 hours to different workflows can be executed like batch processing.

Kinesis can ingest data directly to S3 which makes a good integration to have the data out of the processing workers represented by the Kinesis apps. AWS Lambda (3) is used to process real-time data and the results of this processing are durably stored in DynamoDB (4).

This design promotes scalability on the worker tier (Kinesis Apps) by decoupling the storage to managed services for different purposes.

Summary

This chapter presented several reference architectures that showed how to offload state to external services by decoupling systems architecture and improving on several service domains. We analyzed the full paths for scalable web applications, serverless applications, and streaming data architectures.