If you underprovision (by specifying too few RU/s), Cosmos DB will start throttling performance. Once throttling begins, requests will be asked to retry later when hopefully there are available resources to satisfy it. If an application makes too many attempts to retry a throttled request, the request could be aborted. Refer to Microsoft Doc:

https://docs.microsoft.com/en-us/learn/modules/explore-provision-deploy-non-relational-data-services-azure/3-provision-azure-cosmos-db

Real-time processing is defined as the processing of unbounded stream of input data, with very short latency requirements for processing - measured in milliseconds or seconds. This incoming data typically arrives in an unstructured or semi-structured format, such as JSON, and has the same processing requirements as batch processing, but with shorter turnaround times to support real-time consumption. Refer to Microsoft Doc:

https://docs.microsoft.com/en-us/azure/architecture/data-guide/big-data/real-time-processing

Azure Storage always stores multiple copies of your data so that it is protected from planned and unplanned events, including transient hardware failures, network or power outages, and massive natural disasters. Redundancy ensures that your storage account meets its availability and durability targets even in the face of failures. Locally redundant storage (LRS) copies your data synchronously three times within a single physical location in the primary region. LRS is the least expensive replication option, but is not recommended for applications requiring high availability or durability. Refer to Microsoft Doc:

https://docs.microsoft.com/en-us/azure/storage/common/storage-redundancy

Batch processing of data allows you to schedule a job in an off-peak hour such as overnight. It is also sometimes easier to run a batch of data through a process instead of a constant stream of one at a time. But batch processing does add delay to data processing, and it can happen that a bad piece of data stops the job, affecting other data too.

Blob Storage is the best place to store binary files such as images. Neither Cosmos DB nor Redis Cache can handle large amounts of data such as this, and it does not make sense to do it using SQL Database. Refer to Microsoft Doc:

https://docs.microsoft.com/en-us/learn/modules/explore-non-relational-data-offerings-azure/3-explore-azure-blob-storage

If you only need to perform a task once, or have custom configuration needs, using the Azure Portal to create a resource is probably the best approach. Refer to Microsoft Doc:

https://docs.microsoft.com/en-us/learn/modules/explore-provision-deploy-non-relational-data-services-azure/2-describe-provision-non-relational-data-services

The best answer is the soft delete feature. This enforces a time in which a deleted blob is recoverable. Blob versioning also allows a deleted blob to be recovered. The other two answers do not specifically deal with recovering deleted data. Refer to Microsoft Doc:

https://docs.microsoft.com/en-us/azure/storage/blobs/soft-delete-blob-overview

Azure Databricks offers a SQL platform for analysts to run queries against data, a platform to allow data scientists and engineers to work together on tough data science problems, and a machine learning environment to build, train and test models. Refer to Microsoft Doc:

https://docs.microsoft.com/en-us/azure/databricks/scenarios/what-is-azure-databricks

Storage tables are charged based on the region they are located in, the replication option, the consumed storage, and a few cents per million transactions. Refer to Microsoft Doc:

https://azure.microsoft.com/en-us/pricing/details/storage/tables/

Any program that requires real-time processing and is extremely time-sensitive might want to consider stream processing data