Relying heavily on hundreds of thousands of interconnected database records the primary development issue I face with Munky is the rapid access of data, requiring:

» Fast load times for end-users
» Simplified development for myself

This has been achieved with a set of database wrapping classes to allow for traversal of related records. The need for knowledge of SQL has been almost completely negated with data access being as simple as $photo->event->venue->name to automagically join foreign keys of related tables and access relevant but otherwise distant information (while these photo/event/venue table and field references are specific to Munky the classes automatically generate and cache them, requiring no manual configuration).

Data access by these means will create a cached copy accessable across multiple server instances by utilising Memcached in a similar yet smaller manner to Facebook.

Currently the database acts only as a backup in the event of a cache miss. As database object instances are shared across HTTP requests and data is loaded lazily, load times are very fast. This provides the ability for a significant amount of horizontal scaling of the logic layer with a shared cache infrastructure.