Hey @dsyer I guess I was thinking that you don't want to share databases across services. At least I thought that was the best practice. In this case I am trying to implement a registration service which needs to change the database backing the auth server, so I thought that logic should live there
As I get into the product/order stuff I was planning on using the auth-server db as the source of truth for membership and having teh auth=server add new customers(or updates) to an rabbit mq, to update a mongo instance
OK. I guess that's defensible. Not sure why you need the rabbit layer though.
I thought you might be proxying calls to /oauth/* endpoints (which wouldn't be a great idea)
You could equally well make an argument that the auth server's single responsibility is minting tokens
User and client registration would then logically live somewhere else. But since you called it "uaa" I guess you might be following ( or using) the Cloud Foundry UAA, which has all that stuff co-located.
I was going to look at it :) I was trying to do an application that has everything to get a feel how it all fits together in a more applied sense. I plan on having an admin page that can view the hystrix and eureka dashboards as well.