The data tier consists of the primary application database, application storage, as well as services that keep the database in sync with Cloud Firestore.
AWS offers fifteen different types of managed or serverless database services, each of which is purpose-built for particular workloads. Because Firestore data is document-oriented, we’ll use Amazon DynamoDB, a single-digit millisecond performant, cloud scale, serverless NoSQL database.
To keep things simple and clear for demonstration purposes, we’ll be migrating a small document-oriented schema from Firestore to DynamoDB. The actual data migration process is done automatically during our infrastructure deployment using AWS Step Functions, which orchestrates a series of Lambda Functions to read Firestore data in batches and buffer the writes to DynamoDB through a queue using Amazon Simple Queueing Service (SQS).
Google Cloud Storage is migrated to Amazon S3. These services are actually interoperable, so we can use the Google Cloud SDK to synchronize assets to S3.
We also deploy a Firestore listener service that tracks mutations originating from Firestore and propogates the changes into DynamoDB. This service also triggers AppSync no-op mutations from the server side to push updates to connected clients.
For both the bucket synchronization and Firestore real time listener services, we containerize them using Docker and run them using AWS Fargate, a serverless compute engine for containers that lets us run containers directly on AWS without needing to provision servers.