Everyone has given good advice above me, but I thought I'd add my personal experience as well. I've also worked on projects where speed was critical, and for the most speed-critical parts we used custom persistant caches to keep things speedy.

The implementation of such a cache is fairly straightforward, pretty much a hash with a daemon running around it. During quiet moments the cache is cleaned with old nodes removed and/or flushed to disk/database. Connection is usually via a unix domain socket.

If you have your front-end scripts populating the cache on misses, then you can have a very simple and very fast single-threaded cache. It can be used with any of the other strategies (databases, disk files, DBM files, etc) mentioned above. It can pre-populate itself with information if desired.

I'd suggest you think twice before having your cache make HTTP connections to the remote server. While this seems very elegant from a design standpoint (ask cache, get back answer, don't care about hit or miss), it means you run the risk of your cache being blocked on HTTP, or seriously increasing the complexity of the code. A misbehaving cache can kill your overall performance when everything depends upon it.

Hope that your project gets well and that your customers are blinded by its speed. ;)

Cheers,
Paul