As you can probably guess, we get many requests for information on how to use caching along with ScaleBase. Well, the answer is very simple – always cache.
This, of course, is not a sufficient answer.
The real question is the architecture of the application, and where the caching layers needs to be implemented.
Consider the following architecture:

This is a really basic architecture, and most applications usually start with something similar. Some logic runs on the browser side (mainly AJAX code, but some UI logic does as well). The Apache layer runs your code (for PHP, and just translates Apache to App Server in Java, IIS in .NET and so on). The MySQL server serves as your database.
However, this solution does not deliver stellar performance. Why? Because, we have not implemented any caching layer. So let’s add it.

This solution can improve performance, but prompts new questions, such as when to use the cache and when to read directly from the database. While this is a simple problem to solve in a standalone machine (all reads are done through the cache, writes occur at the database and the write action also invalidates the relevant area of the cache), it is very difficult to implement with MySQL Clustering. For distributed cache solutions you can check GigaSpaces XTP or Oracle Coherence, and of course – Memcached.
Even when using caching, the database can become a bottleneck, and MySQL Clustering is not enough. This is where ScaleBase comes in. Consider the following architecture –

Now the same business logic can enjoy both a scalable caching infrastructure, and a scalable database infrastructure, to be used for massive writes or reads situations. Do note however, that ScaleBase itself, because of the data splitting that occurs on the database layer, can speed up the performance of writes and most read operations. That said – it does not replace your caching layer in any way.
To summarize, you can add caching to your application when using ScaleBase. We even strongly recommend it. Just make sure to choose a caching layer that scales well ; otherwise, your scaling problems will move – from the database tier, to the caching tier.