Another fundamental change that you can easily implement with AWS is offline processing.

The idea behind offline processing is to change your application to execute as little as possible in real time and execute the rest asynchronously through other services. Implemented correctly, offline processing will make your application feel really responsive as most of the heavy lifting is done at a later time by non-real-time services.

To explain this concept, we can take the extreme example of a traditional social network site such as Facebook. When you browse a feed and click on a Like button, it is very likely that internally the application will do a number of operations, including:

• Increasing the internal score of the post such that the same content may be promoted to more people
• Notifying the author to tell him that you liked their post
• Updating the feed of the people who follow you to mention that you liked a piece of content
• Updating your personal feed to include more content from the same author and more content of a similar type
• Changing the color of the link icon to give you the feedback that your click was taken into account:

In terms of user experience, that very last operation is the only operation that needs to happen in real time. All the modifications to the different recommendations systems and notifications can happen later. From a code standpoint, the way this is implemented is by doing the UI update in real time and pushing a message to a queue as follows:

At a later time (think milliseconds to seconds), other systems will read from that queue and process the information indicating that you liked something in a given post.

Queues and offline processing are very common strategies found throughout the web to help with data processing. It makes scaling a lot easier as many processes can consume a single queue in parallel, it helps to control your server load as events will typically be consumed at a flat rate, which in turns helps to smooth spiky events behavior.

Here is a more visual example of write queries in a DynamoDB table. The write pattern is very spiky as we can see on the left-hand side, but by adding a queue in between the event wanting to write to the table and the actual table, we are able to smooth out the write pattern such as that seen later as shown on the right side:

AWS has a number of options when it comes to adding queues to your infrastructure. The main ones are   Amazon Simple Queue Service (SQS), which is a more traditional message queue service, and Kinesis, which is more similar to Apache Kafka. Both services work very differently:

You can refer to http://amzn.to/2hagnrG to read more about Kinesis and http://amzn.to/2haiX0T to learn more about SQS. You can also check out http://amzn.to/2hahDe7 to read about different use cases on when to use SQS and Kinesis.

All the services we have explored in this chapter have in common the fact that they are really easy to adopt and cheap to manage as AWS does most of the operating work required. You don't have to worry about installing the service, updating the operating system, dealing with hardware failure, running out of disk space, and so on. You may wish for similar properties to your application. That's what the idea behind building serverless architecture is.