Design multitenancy implementation

Note that this is a long-term project due to the amount of effort needed.

In the following requirements, each "group" of posts shall refer to an individual tenant.

Background

Users can be either readers or authors; standard, relatively-straightforward permissions. They should not be aware of the concept of "groups" of posts (i.e. tenants; to be explained later – note that grouping posts using tags, folders, etc. is not part of the scope of this issue and is a completely different matter)
Moderators can manage posts within a group (i.e. a group can have one or more moderators).
- They may or may not be aware of the existence of groups
- Groups can have their own properties. Example:
- "public" group – stories are visible by everyone
- "internal-one" - only visible for users of a certain department
- "internal-two" – visible to users of a different department
- "internal-all" - visible to users of either "internal-one" and "internal-two"
- The effect of "multiple" deployments can be achieved by using "tricks" such as sub-domain routing, etc. The idea is that with multi-tenancy, having actual multiple deployments versus a single deployment catering to multiple tenants should be indistinguishable and transparent to users.
Admins ("system" admins) will have a "dashboard" that will allow for the management of these groups
- The implementation should be modular enough such that in the MVP, this can simply be set via configuration files/environment variables (that way an actual frontend dashboard won't be necessary)