Hi eleuthria, hi rjk,

it's nice to have some discussion going on here. I've been thinking about this "federated" or "distributed" pools idea a lot, also got some input from various chats and other sources. Here are some problems and tentative solutions or thoughts that came up, feel free to add comments:

Workers

• Sharing workers between servers is no problem if you have a database which offers replication
• CouchDB is very good at this, syncing up changes in nearly realtime; after a server crashes and recovers, all changes which have been made are grabbed from peer servers; also it offers streaming changes to applications (like ecoinpool)
• MySQL also has replication features, though I've never tried that out; polling for changes from the application would be required though
• A custom database and replication engine for ecoinpool could also solve the task of worker sharing and would be even faster

Shares and Statistics

• Besides worker configuration, all other pool services revolve around shares
• Large pools have to handle shares in masses
• CouchDB can easily get to its limit there and I wouldn't recommend it for shares storage anymore
• Having a central database would produce a bottleneck or single point of failure; only a hidden dedicated server where only the shares database is running would be ok
• The other option is to store & process shares on each server separately; however, this requires a mechanism to sum up the number of shares from each server and present them correctly to the user
• Creating long-term statistics out of short-term shares is also not an easy task; yet this could again be achieved with replication-enabled databases like CouchDB as the amount of data is reduced greatly and record sets drop in comparatively slowly
• Live monitoring is something really cool, everyone who experienced that in ecoinpool's testing phases instantly fell in love with it and wanted to keep it - but it relied on CouchDB which isn't built for monster rigs...
• Work has started on an alternative way to provide live monitoring without CouchDB, but this gets complicated if multiple servers are involved
• The current idea is to have a server-to-server protocol for shares announcement; like this, shares could be pushed via HTTP longpolling from any server to the user's browser

Daemons and Block Solves

• Current pool website software (i.e. cron jobs) detect block solves by querying a coin daemon (bitcoind, namecoind, litecoind...)
• This requires either to connect to all servers in order or having a central instance of the coin daemon or setting all daemons to the same payout address of the central server (currently not supported for namecoin)
• ecoinpool, having a built-in block monitor, could do block solve detection by itself and publish the information somewhere (block hash, Tx ID, number of confirmations, etc.) leveraging the requirement of those cron jobs

Payout

• Payout usually involve processing shares
• If not done correctly, shares could be paid out more than once
• First solution is again having a central shares database and payout
• The alternative is to let each server manage their own presumably partial payout; this is a good decentralized solution but requires some server-to-server communication to make it convenient for the user
• Different payout mechanisms put different demands on the shares database; not all payout mechanisms can be used in a decentralized way
• Legacy systems rely on existing structures (e.g. cron jobs working on SQL databases)