Oui, c'est le "front/back" de la partie back 
Mais je ne sais pas trop comment le formuler...
Les problèmes de réplication ou de forte charge ne se posent pas encore, mais de ce que j'en sais, il est plus aisé d'ajouter des instances MySQL pour répartir la charge du SGBD que des "instances PHP" pour répartir la charge PHP. En tous cas, j'ai pu trouver de la doc pour "ajouter" des instances MySQL, mais je n'en ai pas trouvé pour faire facilement la même chose coté PHP (apparemment, il faudrait un load-balancer amont).
Sinon, ton goulot d'étranglement étant le SGBD, j'ai l'impression que tu es dans le même problème qu'à mon boulot (oui, je m'y réfère souvent, mais bon). A mon sens, ce goulot d'étranglement vient justement du fait que le SGBD est "sous-exploité", en servant juste des données et en passant à coté de certains traitements par lots qu'il saurait faire efficacement.
Pour reprendre l'exemple précédent, le cas type du "je récupère des objets, je les mets dans PHP, puis je complète ces objets avec d'autres objets que je construis là encore en les demandant au SQL" alourdit énormément les traitements (cf Techniques d'utilisation de WHERE IN pour MySQL) car il y a un trafic énorme entre les deux logiciels (PHP et MySQL).
Ayant pu comparer les deux méthodes (taff vs perso), je trouve la 2nde plus agréable, même si les deux fonctionnent
PS: un truc que je trouve pratique aussi avec cette archi, c'est que je peux changer la structure interne des tables sans devoir altérer les classes PHP (je ne sais pas si c'est faisable avec un ORM où la classe PHP "génère" les tables SQL). Par exemple, je ne peux pas utiliser extension MySQL Geometry (car OVH est en v5.5 et non 5.6). Du coup, en interne, mes coordonnées 2D sont sous la forme de 2 colonnes (x; y). Quand OVH passera en 5.6, je pourrai altérer la structure interne des tables pour utiliser 1 seule colonne, de type GEOMETRY. Je n'aurai alors que les procédures SQL à corriger (avec en plus, l'auto-complétion de l'IDE puisque ces fichiers sont des .sql purs), rien à toucher ou regénérer coté PHP.
PSS:
Quand j'aurai fait une release viable d'Eclerd (si je peux faire une telle release), j'essaierai de présenter cette technique et de la mettre bien en forme (façon blog-tuto-pas-à-pas).
Mais je ne sais pas trop comment le formuler... Les problèmes de réplication ou de forte charge ne se posent pas encore, mais de ce que j'en sais, il est plus aisé d'ajouter des instances MySQL pour répartir la charge du SGBD que des "instances PHP" pour répartir la charge PHP. En tous cas, j'ai pu trouver de la doc pour "ajouter" des instances MySQL, mais je n'en ai pas trouvé pour faire facilement la même chose coté PHP (apparemment, il faudrait un load-balancer amont).
Sinon, ton goulot d'étranglement étant le SGBD, j'ai l'impression que tu es dans le même problème qu'à mon boulot (oui, je m'y réfère souvent, mais bon). A mon sens, ce goulot d'étranglement vient justement du fait que le SGBD est "sous-exploité", en servant juste des données et en passant à coté de certains traitements par lots qu'il saurait faire efficacement.
Pour reprendre l'exemple précédent, le cas type du "je récupère des objets, je les mets dans PHP, puis je complète ces objets avec d'autres objets que je construis là encore en les demandant au SQL" alourdit énormément les traitements (cf Techniques d'utilisation de WHERE IN pour MySQL) car il y a un trafic énorme entre les deux logiciels (PHP et MySQL).
Ayant pu comparer les deux méthodes (taff vs perso), je trouve la 2nde plus agréable, même si les deux fonctionnent
PS: un truc que je trouve pratique aussi avec cette archi, c'est que je peux changer la structure interne des tables sans devoir altérer les classes PHP (je ne sais pas si c'est faisable avec un ORM où la classe PHP "génère" les tables SQL). Par exemple, je ne peux pas utiliser extension MySQL Geometry (car OVH est en v5.5 et non 5.6). Du coup, en interne, mes coordonnées 2D sont sous la forme de 2 colonnes (x; y). Quand OVH passera en 5.6, je pourrai altérer la structure interne des tables pour utiliser 1 seule colonne, de type GEOMETRY. Je n'aurai alors que les procédures SQL à corriger (avec en plus, l'auto-complétion de l'IDE puisque ces fichiers sont des .sql purs), rien à toucher ou regénérer coté PHP.
PSS:
Quand j'aurai fait une release viable d'Eclerd (si je peux faire une telle release), j'essaierai de présenter cette technique et de la mettre bien en forme (façon blog-tuto-pas-à-pas).