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 HAQM 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 HAQM CloudFront deployed in a standard AWS Region in this blog, as HAQM 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. HAQM 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 HAQM Simple Storage Service (HAQM S3) in the AWS GovCloud (US) Region. This HAQM S3 bucket serves as an origin for HAQM 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 HAQM API Gateway. The latter publishes the message to HAQM Simple Notification Service (HAQM SNS). Figure 1 uses the HAQM SNS fanout scenario, in which you can publish a message to an HAQM SNS topic, replicate, and send the message to multiple endpoints. In Figure 1, HAQM SNS connects to multiple HAQM Simple Queue Service (HAQM 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 HAQM DynamoDB. Learn more about HAQM 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 HAQM 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, “HAQM S3 + HAQM CloudFront: A Match Made in the Cloud,” details how to securely access content on HAQM 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 HAQM SNS. HAQM 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 HAQM SES SendEmail API. HAQM 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 HAQM S3 bucket using HAQM Kinesis Data Fire Hose. HAQM Kinesis Data Firehose is a fully managed service for delivering real-time streaming data to destinations such as HAQM S3. HAQM SES monitors for events such as email bounce rates, compliance record, delivery record, and more. HAQM SES events are delivered to an HAQM S3 bucket using Kinesis Data Fire Hose for further analysis. Learn how to retrieve HAQM SES event data from Kinesis Data Firehose. These events can be queried by HAQM Athena and viewed in an HAQM 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 HAQM SQS queue. The message is then delivered to an HAQM S3 bucket via Kinesis Data Firehose. The data is stored on HAQM S3 for auditing and to support meeting compliance goals. Learn security best practices for HAQM S3 and how to design your HAQM 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 HAQM Elastic Container Service (HAQM ECS) on HAQM Elastic Compute Cloud (HAQM EC2). HAQM ECS is a highly scalable and fast container management service. With HAQM 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. HAQM CloudFront enhances customer experience by providing a highly responsive and low latency web application for customers based across the US and other countries. HAQM SES improves customer experience by delivering email accurately to the user inbox. HAQM 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