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.}

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 suits your needs of querying. Just remember that the more info It has, the less chance for collision and more information is retrieved per 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.}

I have been thinking a bit about this question and I think I found a way to get composed IDs, meaningful enough for you 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 you 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 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 you might have).

This ID contains many information, easy to query with text search or simple regular expressions.

You could add 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 distribuidoted systems, could be interesting to have 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 

I think URIs provide us with several resources for we to craft meaningful IDs and they are very suitable for distributed enviornments.

No need to say that you 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.

^{* Honestly, the last one doesn't like me as much as the first. If I had to choose, I would go for the first.}

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.}