Note: This question is part of a series of questions that present the same scenario.
Each question in the series contains a unique solution that might meet the stated goals.
Some question sets might have more than one correct solution, while others might not have a correct solution.
After you answer a question in this section, you will NOT be able to return to it.
As a result, these questions will not appear in the review screen.
You are developing an Azure solution to collect point-of-sale (POS) device data from 2,000 stores located throughout the world.
A single device can produce 2 megabytes (MB) of data every 24 hours.
Each store location has one to five devices that send data.
You must store the device data in Azure Blob storage.
Device data must be correlated based on a device identifier.
Additional stores are expected to open in the future.
You need to implement a solution to receive the device data.
Solution: Provision an Azure Event Grid.
Configure event filtering to evaluate the device identifier.
Does the solution meet the goal?
Click on the arrows to vote for the correct answer
A. B.B.
Instead use an Azure Service Bus, which is used order processing and financial transactions.
Note: An event is a lightweight notification of a condition or a state change.
Event hubs is usually used reacting to status changes.
https://docs.microsoft.com/en-us/azure/event-grid/compare-messaging-servicesThe proposed solution of provisioning an Azure Event Grid and configuring event filtering to evaluate the device identifier can partially meet the goal of receiving and storing the device data from POS devices located in 2,000 stores throughout the world.
Azure Event Grid is a managed event routing service that enables the development of event-based architectures. It allows subscribing to events from various Azure resources and third-party applications and routing them to one or more endpoints, such as Azure Functions, Azure Logic Apps, or custom HTTP endpoints. Event Grid can be used to handle events generated from Blob Storage, Azure IoT Hub, or Azure Event Hubs, among others.
In this case, configuring an Event Grid to receive events generated by POS devices and routing them to Azure Blob Storage can provide a scalable and decoupled architecture that allows the decoupling of the data ingestion and storage steps. It also provides the ability to integrate with other services that may need to consume the device data.
However, there are some potential issues with the proposed solution. First, Azure Event Grid is not designed to receive or store data directly; it only routes events. Therefore, it is necessary to have a mechanism to transform the device data into an event before sending it to Event Grid. This transformation can be done by using a middleware, such as Azure Functions or Azure Logic Apps.
Second, Event Grid imposes limits on the maximum size of the event content, which is 64 KB. Therefore, the device data, which can be up to 2 MB per device, needs to be split into multiple events or compressed before being sent to Event Grid.
Finally, Event Grid's filtering capability is limited to a set of predefined metadata properties and custom properties, which may not include the device identifier. If the device identifier is not one of the metadata properties, it may not be possible to filter events based on it.
In summary, the proposed solution of using Azure Event Grid to receive and route POS device data can work, but it requires additional middleware to transform the data into events and overcome the size limitation. Also, the feasibility of using Event Grid filtering to evaluate the device identifier needs to be confirmed. Therefore, the answer is "No," the solution does not fully meet the goal.