Consider a Read Only mode that enable read replica servers

[decentralgabe]

A configuration flag could be added to disable write APIs to enable a single writer, multi reader deployment.

cc: @frankhinek @finn-tbd for more input

[finn-block]

Probably silly questions: are there read-only clients that could plausibly use this? or would we have to put something in front to route write calls to the write server? if we have to have a front-end proxy to route calls to the correct server, I think we should just use something like pgpool to handle that behavior at the database layer. If this is a thing that some clients would actually use, i'm not oppose but it would be nice to have a way for clients to detect that a particular endpoint is read only.

[decentralgabe]

or would we have to put something in front to route write calls to the write server? if we have to have a front-end proxy to route calls to the correct server, I think we should just use something like pgpool to handle that behavior at the database layer

yes, should be invisible to the client

[decentralgabe]

part of me wonders how much this is something we should expose as part of the server here because it assumes a certain deployment model. for example, we could accomplish this by restricting certain HTTP verbs (PUT, POST, DELETE) at a router/proxy level depending on our tooling.

that said it is probably worth it to explore pgpool as you suggested and make it as easy as possible for folks to deploy and scale the service using this repo

[finn-block]

another option I was thinking about would be a config option for a read-only database. Then we can send read queries to that db (if it's set) and only send write requests to the primary. Then we dont need any magic sauce between us and the db.

[frankhinek]

This could be as simple as something that is included in an implementer's guide with a reference example.

As mentioned above, the server itself may not need to have a "read-only" mode as long as it never tries to write to the database for any GET endpoints. You could have multiple servers distributed globally to provide for low latency DID resolution responses but route all PUT/POST requests to one node that is the active writer.