I'm creating a microservice and need some guidance in deciding the architecture. I have a "create" operation that can take up to an hour, and needs to be able to handle a "cancel" request from a user.
The only way I can think of to achieve this (in Python) is
Am I on the right track? Or is this where I should look at event driven microservices? Should I be looking at running 2 threads in my microservice - one executing the create() and one looking for user-input?
The trick here is to understand that your request is a persistent piece of state that needs to be tracked outside the currently executing thread. As such, you really want to externalize it like you would any other piece of state. As external state, it should be persistent, atomic, and scalable.
This could be a file, a database, or, as the commenter mentioned, a task queue like celery. It all depends on the kind of scaling factors you need, whether the data is updateable, do you need to report on it, etc.
Personally, I tend toward a database in this kind of situation, something queryable, not too normalized, etc. Depending on your tech-stack you may already have one, and you should strongly tend toward that solution.
Once you have decided upon your data store, the rest of this is pretty straightforward, decide on the data to store, how often your executing thread needs to check-in, how to clean-up if everything crashes, etc. An hour is a LONG time in compute time, and you should plan for things to go sideways so that you don't leave things dangling.