All requests from clients (browsers, native applications, etc.) are directed to the API gateway. The gateway handles issues such as authorization and rate limiting. Lambda functions are available through a RESTful API: When a request is received, it is translated into an event and calls a Lambda function. This setup also allows building a microservices architecture, as different functions (or even different systems) can be assigned to each REST endpoint and method. The Lambda functions execute the business logic and interact with a database. In this example, we use DynamoDB, a highly scalable NoSQL database service. The function scales automatically and is billed based on the read and write capacity units provided.
Although DynamoDB provides fast and durable data storage, we still lack advanced query capabilities. Therefore, for full-text search and query aggregation, we rely on ElasticSearch, a "search engine-as-a-service."
To synchronize data from the database with the search index, we again rely on Lambda. By registering a Lambda function in the DynamoDB event stream, our function receives an event for all database updates (create, update, delete) and updates the search index accordingly. What's particularly convenient about this is that both the database and our Lambda function automatically scale as needed, and we don't have to worry about updates or the like.
There is one caveat, however: contrary to what the name suggests, the ElasticSearch service currently offered by AWS is less elastic than Lambda and DynamoDB. To be sure, the ElasticSearch servers are managed for us. Also, the instance types and number of instances are configurable. But they do not scale automatically. This can result in DynamoDB and Lambda scaling seamlessly during a traffic peak - but ElasticSearch having to shut down because it wasn't provisioned with enough resources.
Of course, you can write your own scripts to dynamically adjust the configuration or set up a queue to throttle requests. It's just that this goes against the serverless principles, as it creates overhead and complexity for us. That's why I hope AWS expands its Serverless offering with ElasticSearch - for example, with the recently announced Aurora Serverless feature. (Speaking of which this feature offers a good alternative to the setup described here if you prefer SQL-based databases).