goga_x

Только оптимизация:

1. минимизировать число вызовов API ВКонтакте. Для ответа 1 пользователю нужно а) пометить прочитанным входящее сообщение и б) отправить ответ. Это 2 вызова API. До 25 вызовов API можно упаковать в один execute() – так получится отвечать 12 пользователям за 1 вызов execute() и при лимите в 3 вызова в секунду – 36 пользователям в секунду.
   
2. следить за кол-вом вызовов в секунду и не превышать этот лимит: где-то, например, в Redis, держать времена трёх последних вызовов к API. При желании выполнить очередной доставать эти времена и принимать решение: выполнять сразу или подождать N миллисекунд.
   
3. очередь – сообщения обрабатывать не мгновенно при получении сигнала от callback api, а помещать их в очередь. Рабочий процесс берёт из очереди задачи и выполняет – группирует в пачки по 24 и отправляет – с учётом времени предыдущих трёх овтетов.
   

При такой организации вам хватит одного слабенького сервера и вы сможете приблизиться к теоретическому пределу в 36 сообщений в секунду.

Чтобы понять, в чём дело, смотрите ответы ВК на каждый запрос – есть ли там поле error. Пишите их в лог, чтобы можно было разобраться пост-фактум.

Чтобы избежать превышения лимитов при наплыве посетителей, не обрабатывайте запросы синхронно, а устройте очередь задач. Поступил запрос от посетителя – создайте задачу и сохраните её в очередь, а серверу ВК ответьте "ок" и больше ничего сейчас не предпринимайте. Другой процесс, постоянно работающий в фоне, пусть берет по одной задаче из очереди, обрабатывает и шлёт ответ пользователю. Пусть учитывает время трёх предыдущих отправленых вызовов к API ВК. И при необходимости, чуть ждёт, прежде, чем выполнять следующий.

Как мне построить заводик по переработке клубники?
В зависимости от требований читайте про canvas или SVG. На канвасе вроде даже библиотека для орг чартов была.