Architecture Review
I am trying to wrap my head around this https://learn.microsoft.com/en-us/azure/architecture/patterns/async-request-reply by working on a real example.
The idea is that there is some long running request (it could take to minutes). And this pattern is used to make it asynchronous. We have three endpoints
/generate-transcript: This endpoint initiates the transcript generation process for a specific id (given in body). It handles the initial request from the client to start the transcription task. The app then returns a 202 Accepted and a Location header that contains a pointer to the resource status endpoint.
/transcript-status/{requestId} : This endpoint is responsible for checking the status of the transcription process initiated by /generate-transcript. It helps the client monitor the progress and readiness of the transcript. The server responds with an empty 200 OK (or 404 it depends) if the status is unavailable, indicating that the transcript hasn't been generated yet. The client keeps pooling, when the transcript is available the response will be 302 with a Location header that contains a pointer to the transcript resource.
/transcripts/{id}: This endpoint serves the completed transcript upon successful generation.
At the architecture level, I am thinking about the implementation in the given picture.
Any reviews ?
Asynchronous Request-Reply pattern - Azure Architecture Center
Allow decoupling of backend processing from a frontend host, where backend processing needs to be asynchronous, but the frontend still needs a clear response.
6 Replies
1. The Transcription-Request microservice will accept requests and offload the work to the queu
2. The transcription-processing microservice listens for the queue. When the processing starts it will send a notification back to other microservice via the queue telling that the status has changed to In_progress. Similarly, when a transcription is finished, it will save the transcription to db and snd sends a notification back to the Transcription-Request Service to give the Completed status and the transcriptionId.
An alternative architecture would be:
How to compare such solutions? What are the criteria I need to consider? Is there another alternative other than those 2 solutions ?
if the worker really doesn't have to do anything else and never you will have the necessity of having to execute more job types and the amount of jobs is such that it would need a different design from the db in the left, then i could consider the 2nd solution
but you have to keep in mind that when one of these things changes you will have to change and switch to the first solution or it will probably become a mess
my 2 cents
@dont Could you give me an example on something that could require a differet design for the DB ?
there could be many, even non-techincal ones; for example what if the worker was managed from another team? they probably would like to have their own db with their own deseign, deploy/backup procedures, and such, so it would be transformed in a microservice
other case could be the necessity to switch underlying service, say that you have many clients and they tell you they already have paid a service that offers transcription, so they ask if you can integrate it: you would need a database with various models to keep the jobs associated with the subscription because of the different billings and various other stuff, maybe you sell various packages (like 50 jobs or one year or a free tier)