I have been thinking a bit about this question and I think I found a way to get composed IDs, meaningful enough for us to search and correlate files, accounts and transactions.
account_id@sercive_name://file_path/file_name.ext It's basically a URI. Meaningful enough for us to know the account, the file where It came from and the service involved in its processing.
Now, we would have to decide where to put the correlation ID that identifies the whole transaction.
It could be at the query string
account_id@sercive_name://file_path/file_name.ext?transaction=ID Or it could be part of the credentials *
account_id:tx_id@sercive_name://file_path/file_name.ext Services only need to replace service_name by its own name (or any kind of service code we might have).
We could add even more information, as for instance the date of the process
account_id@sercive_name://file_path/file_name.ext?transaction=ID&intake=yyyy-MM-ddTHH:mm:ss+00:00 In distributed systems, could be interesting to know the instance of the service too. For example, as a subdomain
account_id@sercive_name.instance.server_name://file_path/file_name.ext?transaction=ID&intake=yyyy-MM-ddTHH:mm:ss+00:00 No need to say that we could swap the position of the elements. For example
tx_id@sercive_name.instance.server_name://file_path/file_name.ext?account=account_id&intake=yyyy-MM-ddTHH:mm:ss+00:00 Or
tx_id@sercive_name.instance.server_name://accounts/{id}?file=file_name.ext&intake=yyyy-MM-ddTHH:mm:ss+00:00 Just find out which one suites your needs of querying. Just remember that the more info It has, the less chance for collision and more information is retrieved by query.
* Honestly, the last one doesn't like me as much as the first. If I had to choose, I would go for the first.