Instead of writing the image into the local file system, the application could use the feature to store larger files in MongoDB . This allows each application instance to fetch the required files (the image in this example) from the MongoDB server(s).

Imagine a blog where a user writes a post and uploads an image for this post. Let's say the upload request is handled by application instance one, which saves the image into the local file system. From now one the application instance one knows something (the image) that is not known by instance two. When a user now opens the blog post, it could be that the request to show this post is handled by the application instance that doesn't has the image. In this situation the use won't see the image.

A common tactic to make web application scalable is to use a shared nothing architecture. This means there isn't an application instance that knows something another instance doesn't know.

MongoDB as a Store for Log Events (Operational Intelligence)

Use Case Example

When running software systems in production (e.g. web applications, web server, databases, etc.) they are usually configured to produce log messages. For example a web server produces a log message/event for each HTTP requests he handles. This message can contain multiple pieces of information. The most web server for example specify the time when a HTTP request arrived, the URL to which the request was made, the browser that the user used to show the page and so on.

Traditionally log messages are stored in a file on the same machine where the system runs. This makes the analysis of the data hard. Especially when the system is distributed across multiple machines. To stay with the web server example imagine you have a web server cluster, where each web server in this cluster produces log messages. To analyse the log messages you must first gather the messages from each server in the cluster.

Instead of writing these log messages into different files, it is possible to use MongoDB to store these messages. The horizontal scalability of MongoDB allows a growing number of log messages without struggling with hardware limitations. The fact that MongoDB only provides eventual consistent operations doesn't matter because this use case doesn't require a strong consistency.

To allow a huge amount of parallel incoming log messages it is possible to configure MongoDB that it should't care about the durability of the data that much as it would care by default. This doesn't mean the log messages are not saved persistent it just means that when a client inserts a record, MongoDB wont send an acknowledgement back to the client that the operation was successful. This configuration is called Write Concerns and can be configured for each write operation differently.

The aggregation features can be used for effective log message analysing.