@Scott
Right, that's what I meant in the first paragraph. In this case I believe you could have a separate Q2A site that would only handle the registrations so all sites would redirect the registration to that site and it should send back the user to the calling site. I'm not sure it is possible to do so without programming a bit (or making some DNS changes) because, at least, you'll have to block all access to the "user registration site" except for the registration and login sections.
@ProThoughts
I think my answer was considerably misunderstood :)
Based on your comment, it is not clear for you that different sites for different topics requires different posts tables so it is not possible to have one single Q2A instance.
This "Idea is to setup different subdomains which will be targeted for diff topics" somehow contradicts "if there are two sites then they may share QA on both". One Q2A instance means all questions will be shared among all sub-domains and you won't really have different sites (but rather categories at most). Many Q2A instances means each sub-domain will have their own set of questions and won't be accessed by other Q2A instances.
"I liked the option1" => There are no options. There are just very different scenarios (including the awkward external users scenario):
if you want separate questions per site then
use many different Q2A instances
if you want separate users per site then
use different users table
else (users are shared among sites)
if you want a third party to handle your users then
if you want Q2A to be that third party itself then
use single sign on (external users feature) setting up a Q2A instance only used for registration (awkward scenario)
else
use single sign on with whatever your third party user provider is (e.g.: WordPress)
else (users are handled by Q2A)
share the same users table (this is a simple approach!)
else
use one Q2A instance and use categories
I'm going to claim a patent for that algorithm.
"I liked the option1 to have single db for user from main domain" => If by option one you mean having separate questions, sharing users among the different Q2A instances handled by Q2A itself then there is also no such a thing as a "main domain". You just have the sites. You could have a webpage as the domain root or a www. or whatever but that won't have anything to do with Q2A as you'll have Q2A instances per sub-domain.
"if user click on favorite questions on diff subdomain, hope it will populate diff sites his favorite questions in his account" => No, it won't there are different posts tables per instance. Each instance access there own post table. Favoriting a post requires knowing that post. An instance does not know the posts of another instance so each favorited question won't be visible among different sites.
"What if cloud db is setup" => Then the cloud DB will get locked more frequently :)
"what is the user count when I should start worrying about this?" => Will depend on your server (CPU, memory, bandwidth) and the usage you're expecting from the site. I definitely wouldn't worry about this unless you're planning to have a million views per hour. Although this is very subjective and depends on so many factors that you should give it a try and share your experience with the rest (note how very few people complain about performance and the ones that do are most likely in free/cheap hosting plans).
"if SSO is possible with Q2A then could you please provide solution here." => It's on the site:
http://docs.question2answer.org/install/single-sign-on/
"Does it mean only users table will be accessed from diff server with no other tables in that db?" Yes and no. The most standard way of SSO would be to have a third party (different than Q2A) to handle the users. However, you could use Q2A as the third party itself, as I explained before.
