Максим Федоров

Взять все нужные Id, по ним одним запросом взять данные из БД, всем полученным насытить то, что вам нужно

PSR-7 Request -- дефакто стандарт в отрасли https://www.php-fig.org/psr/psr-7/

Вот простой http клиент:
https://github.com/zendframework/zend-diactoros

Пример использования:

// Create a request
$request = (new Zend\Diactoros\Request())
    ->withUri(new Zend\Diactoros\Uri('http://example.com'))
    ->withMethod('PATCH')
    ->withAddedHeader('Authorization', 'Bearer ' . $token)
    ->withAddedHeader('Content-Type', 'application/json');

// OR:
$request = new Zend\Diactoros\Request(
    'http://example.com',
    'PATCH',
    'php://memory',
    [
        'Authorization' => 'Bearer ' . $token,
        'Content-Type'  => 'application/json',
    ]
);

// If you want to set a non-origin-form request target, set the
// request-target explicitly:
$request = $request->withRequestTarget((string) $uri);       // absolute-form
$request = $request->withRequestTarget($uri->getAuthority()); // authority-form
$request = $request->withRequestTarget('*');                 // asterisk-form

// Once you have the instance:
$request->getBody()->write(json_encode($data));
$response = $client->send($request);

Не складывается все пока в единую структуру

Глаза боятся, руки делают

Во внешнем сервисе есть авторизация, добавление/изменение n-го количества сущностей (пользователь, заказ и т.д.). Основная задача паттерна, обойтись малой кровью при замене одного внешнего сервиса на другой, когда потребуется ее заменить. Или возможность переключаться между несколькими внешними системами.

Допустим вы под таким сервисом понимаете сервис доставки -- такой сервис в будущем понадобится подменить, заменить и т.д... Там есть и работа с пользователями и с заказами.

Простой набросок со Стратегией

Можно придумать некий интерфейс клиента:

// Принимает ваши учетные данные
DeliveryClientInterface::__construct(?string $account = null, ?string $password = null)

// Регистрируем покупателя в сервисе
DeliveryClientInterface::registerCustomer(DeliveryCustomer $customer): int

// Получаем заказы покупателя в сервисе
DeliveryClientInterface::getOrders(int $customerId): DeliveryOrder

// Добавляем заказ покупателю
DeliveryClientInterface::addOrder(int $customerId, DeliveryOrder $order): int

// Оповещение покупателя в сервисе о неком действии, связанной с ним в этом сервисе
DeliveryClientInterface::notifyCustomer(DeliveryEvent $event): bool

И научить свой проект работать с таким кодом, через интерфейсы

// что в конструктор сервиса запихнете, например PochtaClient или PickPointClient,
// с тем и будете работать
class DeliveryService
{
    public function __construct(DeliveryClientInterface $deliveryClient, User $user)
}

$userOrders = $this->deliveryService->getOrders($user->getUuid());

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

Далее в клиентском коде подключайте нужный вам клиент через конфиг/контейнер и все будет работать.

Можно призвать make
Особенно когда нужно группировать несколько команд

Вот пример, к сожалению чужой, у меня до Докера пока руки не доходят как следует взяться, Вагрант пока все покрывает
Пример Makefile
Работает в линуксах так: make {command}

А тут посмотрите сколько команд выполняет make init :)

В Extension бандла получите из конфига значение и положите в контейнер (он доступен вторым параметром в методе load()):

$container->setParameter('your.service.name.mapping', $config['menuItems']['mapping']);

И же в контроллер/любой другой сервис пробрасывайте в конструктор эти значения:

arguments:
 - 'your.service.name.mapping'

В порядке действий:

• анализ, что работает медленно (не "заказчик говорит медленно", а например "запрос для товаров, при выборке по акциям и покупателям" работает 2 секунды)
  
• оптимизация кода, работающего с запросами (снижение числа запросов или более точные выборки) -- самая популярная проблема,
  
  - снижал на этом только этапе в 1000-1500 раз,
  - видел по 1500 запросов на страницу,
  - видел 1 запрос, но на всю таблицу и потом по коду с этими данными гигантская работа, когда можно было сделать 2 ооочень шустрых запроса в БД с конечными данными :)
  - запросы в цикле, очень много раз видел (гуглить проблема N+1)
  
  
• оптимизация медленных запросов
  
  Сделать запрос более быстрым, за счет или более точных выборок, или более верного синтаксиса, или стоит например раздробить на нексколько очень мелких, а бекендом все привести к нужному виду
  
  
• индексы (сильно оптимизируют и бывают достаточны для решений многих бед со скоростью на большой выборке)
  
• кеш на стороне БД
  
• кеш на стороне приложения
  
• денормализация некоторых данных, например предагрегация (например меню сайта и нужно для каждого вывести число твоаров, каждый пункт связан с категорией, категорий много, чтобы каждый раз по 100 категорий на подсчет товаров для каждой не делать -- делать это сильно реже и хранить в некой агрегирующей табличке)
  

С техниками типа шардинга/репликации никогда не работал

вполне оправданная, сотку тут все дают, и больше дают (и есть, где сильно больше) и не тяжело такую работу найти

но конторы разные:
- требуют пахать за 10
- требуют многое, а пилить Г в итоге дают
- готовы и давать деньги и условия и делиться знаниями
- готовы обещать, но не давать

рынок огромный, толковых разрабов тяжело найти... хорошие компании или проект -- аналогично тяжело,

ну и никто с джунами возиться не хочет :)

Первое: оплата и подтверждение
Нужно работать адекватно с подтверждением оплаты
вы когда передаете данные заказа, то вы кодируете данные одним ключем
банк раскодирует и потом кодирует вторым ключем и вы уже при подтвержддении их раскодируете также вторым ключем их и смотрите -- какой заказ подтвердил банк

Все платежки, которые я знаю работают по такому принципу:
- выдаются 2 ключа
- туда отправляете данные -- одним кодируете
- полученные данные вторым раскодируете
- в полученных данных есть номер заказа

Второе: очистка корзины
Очищайте корзину сразу после принятия заказа и записывайте заказ в заказы (что логично)
А оплачен заказ или нет -- другая история, у пользователя в случае ошибки оплаты просто будет не оплаченный заказ
Если нужно что-то напомнить -- напоминайте. У вас, мол, не оплачен заказ, оплатите, пока есть на месте товары

Зайдите по скрину в этот раздел меню и добавьте свой action
На скрине уже добавлен

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

остальное сами додумайте и делайте выводы, как дальше действовать, на что делать акценты и с какими возражениями работать... если возьмете мой вывод за правду