Should I treat a worker as another 'user' in my system?

The "right" answer would almost always have edges authenticate with some sort of user account or other auth mechanism.

Why? Because you can limit access of that specific edge interface to only the data they need with the right scopes. For example, a worker only updates orders but can't see payment info. If there was a compromise of the worker it can't update orders, marking them all paid. Or overpaid, triggering a refund.

This doesn't always mean actual users. Maybe you issue access keys to the workers - but you can still limit what the access key can do plus revoke one of needed.

Bottom line, if the API is your core, everyone touching it should be touching it in some way that ensures you can

• limit reach in a breach or exploit and
• revoke access if the token or endpoint is compromised in any way.

Here is how I design similar system :

Client : ios/Android/other mobile clients interact with my API to make some orders or view orders

API : Backend Restful service which handles the requests from clients and UI. If the orders need to be processed asynchronously then we should use Queues, from the question I get that the orders are handled asynchronously.

API should keep the order requests in the DB with the state unprocessed and keep them in the Queue (like Amazon SQS, RabbitMQ etc) and then workers should pick them from the Queue process them and update the DB. We should not expose processing API because that can cause security concerns.

I've always had the fleet of workers interact directly with the database (or queue, whatever has the order state), which might simplify access. But in logs, you want to make sure you can name and trace back to workers, for auditing an order flow. Also, you need to synchronize the workers doing work, and clients grabbing state via the API. If you have a single network identity (like an LDAP user) shared among workers, then the question of which worker did what to which order and when becomes reliant on host names or IP addresses to tell the workers apart in logs. That's easier if the logs come from the workers rather than the API. For example, what is the source address of an HTTP API request if a proxy or load balancer sits in front of the API server(s)?

If you give each worker it's own network identity, that changes things. But then you need to worry about making sure nobody crashes your party by pretending to be a worker.

The reason it hasn't been answered is that it appears to be mixing different levels of abstraction.

It is common to have different categories of users. In this case I see three categories of users of the API:

• Web App
• Client (may use different interfaces than the Web App)
• Workers (may access the APIs using a Web App or client)

It may be better to conceptualize the model by role. These appear to be at least roles:

• Order Placers: Web App, Client
• Order Processors: Workers (There may be different roles for different workers.)
• Database Client: API

In the diagram the Order Placers have been modeled by Interface rather than role. Workers may actually use a Web App and/or a Client.

Most usually yes.

In fact, it's usually the simplest solution, because the authentication and authorization mechanisms need to be built and tested anyway. And, I'd argue for it being the default solution unless compelling reasons surface to bypass the normal auth* rules.

The alternative is to add another set of authentication and authorization modules, increasing the overall complexity of the system and your maintenance burden.