Design for a Microservice callback

Viewed 57

Recently i had a discussion with my tech lead on the following

We have a Media download microservice which downloads media files(audio/video/image), we wanted to limit the microservice's scope to only downloading of various media for different entities in our db and associate them, and wanted to schedule further operations(callbacks) after the completion of the download such as encoding, speaker segregation etc ( things that can occur in parallel)

My tech lead's idea was the following: Let each user along with media url/link also specify the callback in complete details something like

[ 
  {
    callback type : https
    callback url : "https://myinternalserver:port/process/callback
    callback params : []
    callback headers : []
    callback body: []
    callback type : GET 
  }, 
  {
    callback type: sqs,
    callback queueUrl : "",
    callback queueMessageBody : ""
  } 
]

His justification was that this way we wont need to rebuild the microservice every-time we wanted to add some new sort of call back option

My idea for the same was like following

 callbacks : [
     ENCODING,
     PROCESSING
  ]

I wanted the to give the caller the ability to choose the callbacks he wants but the internals of how to actually call the callback and what sort of params, body etc is needed is abstracted from him

In my case every-time there is a new callback added i need to write code in my microservice to include that in my system and deploy it to allow the client to use it,

but the advantage of my system is the client calling this microservice doesn't need to know the callbacks interfaces in great deatils and thus removes the dependency from the client side to know every callbacks urls, possible message structure, params etc.

Even though my managers solution is alot of more generic for the microservice but it puts alot of responsibility on the client side and demands the client to know alot of details about alot of services

Any suggestion as to which is better or if none of the above is a good choice and there exists some other better alternative for the same, really interested in the views/opinion of people who have implemented something similar at scale

0 Answers
Related