По своей сути данный подход означает, что приложение использует множество программных компонентов, слабо связанных между собой. Такая архитектура появилась, как альтернатива на превалирующий когда-то подход: монолитный сервер приложений, объединяющий язык программирования, базу данных, веб сервер и даже часть операционной системы в один процесс (например, Java).

И когда приходит время увеличить размеры приложения, это может стать основной проблемой: практически невозможно распределить монолитный процесс на физически разные компьютеры, поэтому монолитным приложениям требуются очень мощные сервера. Такие сервера, естественно, стоят десятки и даже сотни тысяч долларов, что препятствует их использованию небольшими компаниями и физическими лицами, всегда испытывающими нехватку денег.

Сообщество LAMP, однако, обращает внимание на то, что если разбить каждую часть веб приложения на отдельные компоненты, то вполне можно стартовать с недорогого сервера и просто добавлять такие же сервера по мере роста проекта. Если сервер базы данных за 3 тысячи долларов не справляется с нагрузкой, достаточно просто купить ещё один (второй, третий или четвертый) столько раз, сколько потребуется. Если потребовалось дополнительное дисковое пространство, несложно добавить еще один NFS сервер.

Для того, чтобы такой подход всё-таки работал, веб приложения не должны быть привязаны к одному серверу при обработке запроса, или даже части запроса. В сильно распределенных LAMP (и Django) системах по крайней мере полдюжины серверов могут использоваться для выдачи одной веб страницы! Вариантов построения таких систем множество, но все они сводятся к следующим принципам:

Как и следовало ожидать, Django соответствует этим принципам более или менее точно — ни один из компонентов Django не нарушает данного подхода — но знание его основ поможет, когда наступит время для увеличения размеров приложения.