Split backend based on Kubernetes replicability

I shall elaborate on what this issue should cover.

You see, we will inevitably need to deploy this service onto Kubernetes cluster and ideally make it more production-grade by having multiple instances, replicas of the backend API deployed. However, currently some parts of the backend is not suitable for replication, for instance there would be no point in performing AIoD updates in each backend replica (potentially it could be useful, so that we wouldn't have a single point of failure, etc... but let's not get ahead of ourselves...).

To this end we need to identify and separate these logical units into their separate services rather than having them run under the main FastAPI backend. The following list contains logical parts that we don't wish to replicate on Kubernetes at this particular stage. This list is not necessarily complete, it only contains parts of the application I've thought of so far:
- Asset sync up logic with AIoD platform (Embedding thread, milvus cleanup thread, tinydb cleanup thread)
- TinyDB database
- Milvus database