PATCH /orders/42 

{"status": "reserved"}

update orders set status = "reserving" where id = 42

PUT /reservations/42/

{
  "items": [ 
   {"product":17, "quantity":10},
   {"product":5, "quantity":1}
  ]
}

• Если находит, то проверяет, совпадают ли указанные в запросе продукты и количества с reservationItems where orderId = 42. Если совпали — то возвращает 200 Ok с ETag, вычисленным как хеш от всех продуктов и количеств. Если не совпали — возвращает 409 Conflict. (Тут на самом деле чуть сложнее, но в данном конкретном сценарии эту сложность можно пока проигнорировать)
  
• Если не находит, то делает
  

  begin transaction;
  update stock 
    set reserved = reserved + 10,
        available = available - 10 
    where productId = 17;
  update stock 
    set reserved = reserved + 1,
        available = available - 1 
    where productId = 5;
   
  insert into reservations(orderId) values(42);
  insert into reservationItems(orderId, productId, quantity) values(42, 17, 10);
  insert into reservationItems(orderId, productId, quantity) values(42, 5, 1);
  commit transaction

  
  Эта радость может быть прервана constraint availability check(available >= 0) или ещё чем-нибудь — тогда сервис отдаёт обратно 4хх c понятным клиенту объяснением.
  Конкретный SQL тут не так важен — важна его атомарность. Если мы всё же довели транзакцию до конца и получили в сервисе А положительный ответ от СУБД, то мы в ответ на это отдаём сервису Б
  

  201 Object Created
  ETag: 0x213123123412312
  
  {
    "items": [ 
     {"product":17, "quantity":10},
     {"product":5, "quantity":1}
    ]
  }

update orders set status = "reserved", reservationETag = 0x213123123412312 where id = 42