Webservice requests never use a slave database because last-write time is unknown
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Launchpad itself |
Triaged
|
High
|
Unassigned |
Bug Description
Webservice requests are stateless, and are forced to always use the master database to avoid problems caused by replication lag.
This is not scalable, especially when we consider that the webservice will be used for operations deemed too expensive to be implemented in the webapp. Webservice requests should use a slave database whenever possible, just like our web application does.
I can think of a few options to do this:
- We could require Launchpad API clients to support cookies, and use our existing session management.
- We could allow Launchpad API clients to generate and send their own session identifier, which we could hook into our existing session management.
- We could allow Launchpad API clients to send the 'last write time' with their requests. Launchpad can then issue queries on a slave when it knows all previous writes from the client have been replicated.
If the session identifier is deemed optional, we need to carefully consider the default behavior. If we continue the current policy of always using the master database, then we risk overloading this single point of failure.
Another option would be to use the IP address of the client as a session token if none was passed explicitly. This won't be optimal though due to masking from NAT and web proxies.