The following diagram is a typical flow of data from a sensor to a dashboard. Data will transit through several mediums (WPAN links, broadband, cloud storage in the form of a data lake, and so on). When we consider the following architectures to build a cloud analytics solution, we have to consider the effects of scaling. Choices made early in the design that are suitable to 10 IoT nodes and a single cloud cluster may not scale effectively when the number of endpoint IoT devices grows to the thousands, and are based in multiple geographies:

The analytics (predict-respond) portion of the cloud can take on several forms:

• Rules engines: These simply define an action and produce an outcome. 
• Stream processing: These are where events like sensor readings are injected into the stream processor. The processing path is a graph where nodes in the graph represent operators, and send events to other operators. The nodes contain the code for that portion of the processing, and a path to connect to the next node in the graph. This graph can be replicated and executed in parallel on a cluster so it is amenable to scaling up to hundreds of machines.
• Complex event processing: This is based on queries like SQL and written in that higher level language. It is based on event processing, and is tuned for low latency. 
• Lambda architecture: This model attempts to balance throughput and latency by performing batch processing and stream processing in parallel on massive data sets.

The reason we talk about real-time analytics is that the data is streaming non-stop from millions of nodes simultaneously and asynchronously with various errors, format issues, and timings. New York City has 250,000 street lights (http://www.nyc.gov/html/dot/html/infrastructure/streetlights.shtml). Say each light is smart, meaning it monitors whether there is movement nearby, and if so, it brightens the light; otherwise, it remains dimmed to save power (2 bytes). Each light may also check if there is a problem with the light that needs maintenance (1 byte). Additionally, each light is monitoring temperature (1 byte) and humidity (1 byte) to help generate micro-climate weather predictions. Finally, the data also contains the light ID and a timestamp (8 bytes). The aggregate of all the lights nominally produces 250,000 messages a second, and can peak to 325,000 due to periods of rush hour, crowds, tourist sites, holidays, and so on. All in all, say our cloud service can process 250,000 messages per second, that implies a backlog of up to 75,000 events/second. If rush hour is truly 1 hour, then we backlog 270,000,000 events/hour. Only if we provide more processing in the cluster or reduce the incoming stream will the system ever catch up. If the incoming stream drops to 200,000 messages/sec during a quiet time, the cloud cluster will take 1.1 hours to resolve and consume 585 MB of memory (270 million backlogged messages at 13 bytes per message). 

The following equations formalize the capacity of a cloud system: