Solution one: single sql database

[Roger Dingledine <arma@mit.edu>]

There is a single huge well-connected server with a fast sql-based
database that stores all of the news articles, indexed by date, category,
etc. 

Definitions:
master: the machine with the news database
user: a person who wants to read news
client: sites that distribute news to users

Each news article is given a nonce (a timestamp from the master) so clients
can keep track of the order of news in the database. When clients connect,
they provide the timestamp of the last news article they got, and the master
gives them newer articles. (This implies that clients store a local copy of
the database on their machine.)

Submissions are given to the clients, and they pass them on to the master.
If the master is down, they spool them locally until the master comes up.

Advantages:

* This is very easy to implement, compared to more distributed models.
* This keeps the load off client machines like freshmeat and slashdot,
  who should be spending their load on user requests rather than client
  requests.

Disadvantages:

* This relies a great deal on the master being stable and fast. 
* It does not scale well, when we have hundreds of clients submitting. The
  master has to get faster and faster.
* If the master goes down, no new articles will appear until it's
  back up, and clients can't easily share news between each other.

Conclusion:

The main drawback of this model is that it is too centralized -- it
relies too heavily on a single machine being up and fast enough to do
the job. Its only advantage is that it's straightforward to implement.
Imo this is not worth it.