Sergey Pashkevich

Laravel прекрасен и продуман ) В нём есть и заготовка для организации Очереди задач.

В общем ваша задача выглядит как преобразование из возможно параллельных запросов в последовательные.
Очередь задач с единственным рабочим для этого вполне подходит.

Через artisan создайте новый Job и перенесите в него логику обработки запроса. При поступлении api запроса просто создавайте новую задачу и возвращайте мгновенно ответ "Ок, принято".

Рабочий будет постоянно работать: обрабатывать долгоиграющую пачку или ожидать поступления новой задачи. Точно не возьмётся за 2 параллельно.

p.s. почему так долго обрабатываются 1000 чеков? База тормозит при вставке? Индексы не те?

Посмотри в сторону библиотеки omnipay.
Там уже куча банковских провайдеров и относительно простая интеграция с laravel.

как-то так

...
  sum(i.count)
from sales
join (
  select sale_id, count(*) count from sale_items
) i on (i.sale_id = sales.id)
group by DATE(event_date);

Отвечу опираясь на тему и Ваш комментарий

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

Вариантов реализации множество, я напишу как бы сделал я:

1. Одна база данных и вот почему:
- Легко поддерживать
- Исключает ситуацию когда пользователь подключится не к той БД (если один домен)
- Не будет проблем если вы решите разделить БД, так как id будут по прежнему уникальны. (ибо обьединить гораздо сложнее)
- Сложная реализация вашей идеи в несколько БД
P.S. Выводить определенный товар и не смешивать их, это столбец добавить и 2 слова к запросу дописать. Так же и с авторизацией + есть возможность писать что то в духе "Ваш аккаунт не поддерживается в этой стране"

2. Для каждой страны свой домен (любого уровня, не важно) и вот почему:
- Правильное индексирование поисковыми системами
- Легко поддерживать
- Проще мониторить и отслеживать статистику
- Фильтровать пользователей
P.S. Если хотите запретить доступ Х страны к магазинам Y страны, то лучше на домене Y страны запретить "диапозон IP" X страны

3. Отказаться от распределения пользователей по IP, причины просты:
- Нет 100% гарантии что человек попадет на нужный домен/язык и т.п.
- Будут проблемы с поисковиками
- Пользователи не смогут выбирать
- Пользователь привязан к стране (что уже дикий бред)
- Море звонков в ТП с вопросом "У меня ничего не работает!!!"

0. к слову:
- вы сами себя ограничиваете и это плохо
- я уверен что есть аналоги по архитектуре вашей идеи, которые реализованы верно

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

Вы можете использовать специально созданный для этого токен APP_INITIALIZER
Благодаря нему приложение не будет стартовать пока не получите данные.
Делается это примерно следующим образом.
Регистрируете в провайдерах глобальный сервис и этот токен

providers: [
  GlobalService,
  {
    provide: APP_INITIALIZER,
    useFactory: (service: GlobalService) => () => service.init(),
    deps: [GlobalService], multi: true
  }
],

Сервис примерно такой

@Injectable()
export class GlobalService {
    data: any;
    constructor(private http: Http) { }
    init(): Promise<any> {
        var promise = this.http.get('src/data.json').map(res => res.json()).toPromise();
        promise.then(data => this.data = data);
        return promise;
    }
}

И потом получаете к примеру в корневом компоненте свои данные

export class AppComponent {
  constructor(private service: GlobalService) {
    console.log(service.data);
  }
}

Живой пример

A distributed system is a software system in which components located on networked computers communicate and coordinate their actions by passing messages. The components interact with each other in order to achieve a common goal.

Мне кажется более чем понятное определение.

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

Это один из основных подходов при построении реально больших проектов. Можеет так же почитать про микросервисы и другие схожие подходы.

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

Пример на питоне

import hashlib
h = hashlib.md5('my_cool_filename').hexdigest() # получили 16-разрядную строку
# h =  '13061a556715c93e5543f20b7001c669' - это строка
hi = int(h,16) # перевели ее в лонг
# hi = 25287019810011413006158894310673729129L
index = int(h,16) % 5 # нашли остаток от деления
# index = 4L

Еще раз, нужно не делить, а взять остаток от деления, операция %

$scope.$$phase || $scope.$digest()
Решило проблему, прежде чем вызвать $digest проверяем не запущен ли уже digest($apply)
Осталось всё же непонятно, почему во вьюхе всё было без изменений

Docker или Vagrant + Ansible/Puppet для окружения.

Вы правы.
А вообще не нужно задумываться ни о каких префиксах в 2015 году, используйте autoprefixer.

не стоит удивляться: в таких вакансиях расставляют требования точно так же как и вы теги к своему вопросу.