First, you configure your tenant with the AWS credentials of an IAM user and a SNS topic ARN that you wish to publish notification events to. This can be on your own AWS account so that you can work with these notifications any way you'd like.
The notifications are for a variety of node lifecycle events. The primary one is "node_invalidation" which happens whenever a node's state changes. It's an indication that anyone caching anything downstream might want to reconsider their cache state.
In terms of out-of-the-box and Node.js, what we provide is an SQS listener in the cloudcms-server module. What you do is set up an SQS queue in Amazon and hook it to the SNS topic. That way, any notifications get placed into the queue.
By being in queue, node.js cluster members (i.e. subscribers) can pick up the notifications in order as they arrive. This allows for eventual consistency (non-transactional). The Node.js cluster members hear these events and wipe down their cache as they find time.
The first step I'd recommend is to set up an IAM user with full authorities to an SNS topic and SQS queue. Then hook them together - on your Node.js cluster instances, you can either change the config provided to the start method, kind of like this:
config["notifications"] = {
"enabled": true,
"type": "sqs",
"configuration": {
"queue": "<awsQueueName>",
"accessKey": "<awsIamAccessKey>",
"secretKey": "<awsIamSecretKey>",
"region": "<awsRegion>"
}
};
Or you can provide these values through environment variables:
CLOUDCMS_NOTIFICATIONS_SQS_QUEUE CLOUDCMS_NOTIFICATIONS_SQS_ACCESS_KEY CLOUDCMS_NOTIFICATIONS_SQS_SECRET_KEY CLOUDCMS_NOTIFICATIONS_SQS_REGION
The latter is useful for container-based configuration and is steadily becoming the preferred way to do cloud deployments.