(1) Would such a view allow caching at the view level? If yes, will the book review update the author bio instantly on updating the author bio, or will there be a delay until the cache clears?
The criteria for Views caching are explained in some detail here:
https://toolset.com/documentation/user-guides/front-page-filters/how-to-use-views-parametric-search-on-large-sites/
In your case, these criteria are important:
- The View shortcode has any attribute other than name, id or target_id....
- The View is nested or has a filter or an option that depends on the current page, current user, or current archive data.
- Things that also change the content or the status of posts, terms, or users will invalidate cache automatically.
This View of the author bio must either include a shortcode attribute which sets the context for the author bio, or it must be based on a relationship to the current page. In either case, Views caching is disabled.
(2) If I use an external caching plugin (e.g. W3 total cache, WP super cache), will these cache such post relationships? Could this lead to delays?
I can't really speak to how other specific 3rd-party systems work, but generally caching plugins produce static HTML versions of a site based on the output generated by the server. Then instead of querying posts again next time someone visits, the static HTML version of the page is served. Post Relationships aren't cached per se, but the overall HTML output generated by the page is cached. As far as leading to delays, it depends on the settings and configurations of those 3rd-party caching systems. The delay is completely controlled by their system and depends on when their cached version is programmatically invalidated.
(1) Can these multiple relationships provide an issue with relation to scaling, or is this level of volumes / complexity manageable under toolset?
Any relational system is going to experience slower query times as database size and query complexity grows. Simple queries like posts by a specific author are going to remain pretty fast. Complex queries like the 12 most recent video reviews by the author of a video review related to the current course review and having a specific custom field value are going to be slower. If you're asking me about your specific numbers and configurations, it's not really possible for me to predict accurately because it depends on too many variables. I suggest setting up a test site and using a plugin like FakerPress to generate some dummy content, then run some performance tests on both the front-end and back-end.
Managing post relationships between thousands of posts in multiple post types in the backend sounds...challenging. What if I want to relate 200 existing video reviews to a new course review? Each one of those connections must be made manually, either by selecting all 200 video reviews in the course review post, or by editing all 200 video reviews and selecting the course review post. While it is possible to use a CSV to import posts and maintain existing post relationships, there is no bulk-relate feature in wp-admin for existing posts.
On the other hand, a taxonomy-based classification might be more practical. Instead of selecting all related posts through a manual relationship process, you apply a single taxonomy term to all related posts. Then you can create a View of posts filtered by term to display related posts from each post type.
I recommend you perform tests to see how workflows will be impacted with the numbers of posts you have mentioned.
(2) If I consider the base version of a cloudways cloud hosting (1GB RAM, 1 Core, 1 TB bandwidth), is it possible to give a very rough ballpark estimate of how many concurrent users / monthly visitors can be supported?
No, it's really not possible for me to predict performance because there are too many variables. My best advice is to set up a test site and import some dummy content. Add some post relationships between that dummy content. Then set up some Views that show related content. Then you can run some performance tests on the front-end of the site.