Improving the customer experience for high-traffic public services: An architecture guidance

Improving the customer experience (CX) has emerged as an imperative for government agencies following the 2021 Executive Order on Transforming Federal Customer Experience and Service Delivery to Rebuild Trust in Government.

In other blog posts, we described how the cloud enables transformational citizen experiences, and provided an architecture framework for transforming federal customer experience and service delivery, plus how to improve government customer experience by building a modern serverless web application in AWS GovCloud (US).

Watch now: Learn how AWS powers government transformation.

In this blog post, we build on that foundation and present an architecture pattern using Amazon Web Services (AWS), composed of a curated set of microservices, that public institutions can use to improve CX while building and deploying secure, resilient, and performant web applications that support sudden surges in demand for public services. This architecture pattern meets the need of an example use case in which an agency must request information from thousands to millions of civilians, who may access a single-page application at similar times, and then sends email notifications to each civilian to confirm their activity.

Several agencies require their workloads to adhere to the Federal Risk and Authorization Management Program (FedRAMP) High Baseline. Web applications built in the AWS GovCloud (US) Region can accomplish this objective. Note: to provide a highly responsive and low latency application across the US and other countries, we use Amazon CloudFront deployed in a standard AWS Region in this blog, as Amazon CloudFront is currently not available from the AWS GovCloud (US) Regions.

Customer use case: Requesting and storing information from users, and confirming receipt

Across the federal landscape, government agencies need to engage a large population of citizens to request and retrieve critical information for a variety of programs. These transactions must occur quickly and securely to promote a positive customer experience and not erode public trust in the federal agency.

In this scenario:

Citizens are asked to access a web or mobile application to submit information.
The application accepts and persists the information to be processed.
An email notification informs the citizen that the submission was successful.

Figure 0: The citizen engagement flow for this use case: the citizen is asked to use a mobile app or web app to provide information, and an email notification is sent to the citizen to confirm receipt.

For many of these scenarios, the citizen engagement solution must scale rapidly and support data intake with peak usage of several millions of users within a short time interval. There is also the strict requirement to transmit and store personally identifiable information (PII), and other sensitive data, securely. Auditing and logging are extremely important to these use cases to verify transactions and aid in potential error remediation. The applications and infrastructure providing these services must also be resilient to any disruption that can impact CX. Agencies can leverage the architecture pattern discussed in this blog for developing modern, scalable customer experience applications with serverless technologies on AWS.

High-level architecture pattern for requesting and storing information from users, and confirming receipt

The following Figure 1 illustrates a high-level architecture diagram for a single page application (SPA), built using any front-end framework or library, such as Angular or React, that requests users to submit information through the app, stores that information securely, and then submits a confirmation of receipt back to the user. This event-driven architecture pattern is a distributed asynchronous architecture pattern used to produce scalable and resilient applications. This architecture includes decoupled, single-purpose event processing components that asynchronously receive and process events. The architecture diagram is resilient out-of-the-box: the services shown in the diagram are deployed in a single, highly-available AWS Region with multiple redundant Availability Zones (AZs), so that no single computer, network, or AZ failure can make messages inaccessible.

The reference architecture in Figure 1 uses services deployed in AWS GovCloud (US) and the AWS standard region. Amazon CloudFront is not available within the AWS GovCloud (US) Regions and is deployed across the AWS standard region in this architecture pattern. Please refer to these tips on how to use CloudFront to access the static content of the SPA hosted in Amazon Simple Storage Service (Amazon S3) in the AWS GovCloud (US) Region. This Amazon S3 bucket serves as an origin for Amazon CloudFront distribution.

Using this architecture, users access the SPA via a web browser or mobile application over the Internet. The SPA captures user information (e.g., name, date of birth, email address) and relays the information to Amazon API Gateway. The latter publishes the message to Amazon Simple Notification Service (Amazon SNS). Figure 1 uses the Amazon SNS fanout scenario, in which you can publish a message to an Amazon SNS topic, replicate, and send the message to multiple endpoints. In Figure 1, Amazon SNS connects to multiple Amazon Simple Queue Service (Amazon SQS) using standard queues.

Note that if your architecture has a requirement to preserve data in a highly scalable and fast response data store, AWS offers serverless database services like Amazon DynamoDB. Learn more about Amazon DynamoDB.

Figure 1. High-level architecture diagram for a scenario in which a user is requested to submit information through an SPA, and then a confirmation is sent to the user when the information is submitted.

Sub-components of the architecture

Let’s dive deeper into each of the sub-components of this architecture guidance.

User access

The following Figure 2 illustrates the user access through CloudFront, set up within the AWS Standard Region. An Amazon S3 bucket within the AWS GovCloud (US) Region serves as an origin for CloudFront distribution. CloudFront helps improve the customer experience by speeding up the delivery of static content in the SPA to viewers across the globe. The blog post, “Amazon S3 + Amazon CloudFront: A Match Made in the Cloud,” details how to securely access content on Amazon S3 using CloudFront.

AWS WAF, a web application firewall, lets you monitor the HTTP and HTTPS requests that are forwarded to CloudFront, and control access to your content. Based on conditions that you specify, CloudFront responds to requests either with the requested content or blocks access to the content. Refer to the documentation, Using AWS WAF to control access to your content, to learn how to set up AWS WAF with CloudFront.

Figure 2. The user access sub-component of the high-level architecture.

Email confirmation

The following Figure 3 shows how the email confirmation is sent to users. Timely email confirmation of user activity serves an important purpose in enhancing the customer experience. Email confirmations verify that an action taken by a customer has been successful. In our high-level architecture, raw data from the customer is published by the API Gateway to Amazon SNS. Amazon SQS subscribes to this message and queues the message. An AWS Lambda function retrieves the message from the queue, processes the message, and uses the Amazon SES SendEmail API. Amazon SES sends the confirmation email to the user.

This architecture is also designed to handle errors. Messages that cannot be processed in the queue are sent to a dead-letter queue (DLQ). This is useful for debugging your application or messaging system. DLQs let you isolate unconsumed messages to determine why their processing did not succeed. These messages can be delivered to an Amazon S3 bucket using Amazon Kinesis Data Fire Hose. Amazon Kinesis Data Firehose is a fully managed service for delivering real-time streaming data to destinations such as Amazon S3. Amazon SES monitors for events such as email bounce rates, compliance record, delivery record, and more. Amazon SES events are delivered to an Amazon S3 bucket using Kinesis Data Fire Hose for further analysis. Learn how to retrieve Amazon SES event data from Kinesis Data Firehose. These events can be queried by Amazon Athena and viewed in an Amazon QuickSight dashboard to build visualizations, perform ad-hoc analysis, and quickly get insights about events.

Figure 3. The email confirmation flow sub-component of the high-level architecture.

Data storage for audit and compliance

Figure 4 shows how user data is stored for auditing and supporting compliance needs. An AWS Lambda function processes the messages from the Amazon SQS queue. The message is then delivered to an Amazon S3 bucket via Kinesis Data Firehose. The data is stored on Amazon S3 for auditing and to support meeting compliance goals. Learn security best practices for Amazon S3 and how to design your Amazon S3 buckets to be secure in this documentation.

Figure 4. The services that support storing user data for audit/compliance needs sub-component of the high-level architecture.

Data processing

The following Figure 5 shows the services in the architecture used to process and validate user data. This architecture uses Amazon Elastic Container Service (Amazon ECS) on Amazon Elastic Compute Cloud (Amazon EC2). Amazon ECS is a highly scalable and fast container management service. With Amazon ECS, your containers are defined in a task definition that you use to run an individual task or task within a service. Data received from the user is processed and verified for authenticity, after which further action can be taken.

AWS provides customers with the flexibility to choose a strategy for building modern applications that map to their business needs. The Serverless or Kubernetes on AWS page provides prescriptive guidance on choosing the approach that may be best suited for your environment to build modern applications on AWS.

Figure 5. The data processing sub-component of the architecture.

Security on AWS

Security and compliance is a shared responsibility between AWS and the customer in the AWS Shared Responsibility Model. Use the design principles of the Security Pillar in the AWS Well-Architected Framework to build a security framework that can protect valuable data.

AWS can help government agencies scale rapidly to deliver on CX

In this blog, we presented an event-driven architecture pattern for delivering an improved CX for high performance, secure, and resilient web application using AWS serverless technologies. Amazon CloudFront enhances customer experience by providing a highly responsive and low latency web application for customers based across the US and other countries. Amazon SES improves customer experience by delivering email accurately to the user inbox. Amazon SES can achieve high accuracy in delivering emails with a combination of investments into reputation, engagement, and trust.

To get started on a proof-of-concept or implementation project using this reference architecture, or to learn more about AWS serverless and managed services, contact your AWS account team or reach out to the AWS Public Sector team for more information.

AWS Public Sector Blog