Tracking Distribution Systems
This was a normal day until my teams rings i was surprised who was an old client who two years ago i helped with a system for paid tickets using api from providers of that area.
That was the first meeting to talk about architecture for a massive payment tickets this project is related for almost 3 o 4 companies for validated several business rules for know if the ticket can be paid this was interesting my first think event system, because the client can be submit almost 10-5000 tickets in the same time, the client has a limit a budget for paid the tickets and the amount of ticket is only know when the first query is requested this query is request to api but the api only return 1 validation ticket for request so you know the process maybe is a little slowing the alternatives is create batchs of rows and create micro-services for made the requests or made threads for managing the request also the count the request can be problem if increase the threads or microservices make accident DDNS.
This is a problem or not a problem a possible problem when a make request to the provider, so we made a queue for each ticket, and make in the database a status for know if the ticket was validated, in this point was the start of use Service bus for queue, topics of system.
The teams reunited to choose if the solutions queues are something the project can be managed also the priority of project is this:
- Traceability or another word to know where every ticket is submitted in the process from start to end and more if we have almost 5 services to make differents tasks like, validate with 3 different providers, later make post request to 4 providers and make notifications about the ticket and the last to show our user the results about the paid the ticket.
So, the PO make this question: If a client called asking how much least for their ticket we know to response or maybe show in screen too. But also, if we have an error, we the providers we need to know what the data we sent and receive from their this is very important because this provider never know (i don't know why but that's ok is part our job).
Our answer is this stack:
.Net 8
Aspire
Connection Application Insight (For this install a nuget package and uncomment a method in service default of aspire service default that was all)
Open Telemetry (Second Options)
Grafana for dashboard (i want to make power bi but for now i figure out how connect power bi with application insight)
The preliminary test i can connect Grafana with several data source the bad news for the company is the dashboard for Grafana in azure they need pay for user almost the user a vm for Grafana and hosted that dashboard for me that is more powerful because i have more control, but the company is who decide what is the poison like a professional a make my recommendations.
In Grafana dashboard the idea is the all logs, trace (Activities) create in the services is write in trace table in application insights that table Grafana has access for the datasource azure monitor, make a variables for batch_id and make a filter in each panels and visualizer for filter with that span for trace and logs that way the support user can has access to all informations related a one ticket include the amount paid, and query against database for now the max information for detect fails and the request and response of providers too.
