At any time on a single systemd machine you'll have 1 system manager and 0…n user managers running. This model is built around the traditional UNIX security model: UIDs are the primary security concept of the system, and thus we give each relevant UID a service scope of its own.

While the original purpose of the per-user service manager is to provide functionality for actual human users logging in interactively people have been using the concept for other purposes as well:

If one gives each "project" a user ID, then each project can define their own services, and one can "start" the project as a whole and terminate it by starting/stopping the user's (i.e. projects's) service manager.

This approach works fine, but it has various limits. For example, on UNIX it's not easy to get rid of users after creating them once. Because files are owned by UIDs, and there's not nice way to get from an UID to all files it owns (including on removable media, and such), …

… you cannot just delete a user and expect it's data to be gone too.

Except, that of course you can, because in systemd we have this nice little DynamicUser= concept: if you turn that on for a service it will allocate a user transiently while the service is running, and make it go away once it terminates. By running the service inside a tight mount namespace with very minimal write access only the functionality makes sure that the file removal problem becomes manageable: