Это большая организационная работа по привлечению отелей к сотрудничеству и предоставлению информации о резервировании мест. Очень чётко отлаженное B2B ноу-хау. Priceline (Booking.com) одной из первых начала двигаться в этом направлении и теперь имеет капитализацию в $32B.

Многие нынешние компании используют API с информацией об отелях от самого Booking.com для бОльшего охвата аудитории, наряду с собственной локальной базой отелей.
По состоянию на прошлый год, например, небезызвестный Ostrovok.ru использовал несколько сторонних API в дополнении к собственной базе российских отелей.
Технологическая составляющая B2B сотрудничества может заключаться:
— в предоставлении отелям SaaS-платформы букинг-сервиса для оперативного (онлайн) резервирования. В этом случае букинг-сервис владеет всей необходимой информацией в реальном времени и может осуществлять резервирование с большой степенью автоматизации. Клиент делает заказ в интерфейсе букинг-сервиса, а автоматизированный бек-офис проводит транзакцию резервирования. При успешной транзакции, клиент получает подтверждение бронирования, а владельцы отеля уведомляются через интерфейс SaaS-платформы о новом резервировании.
— в выгрузке статистики отеля пост-фактум (через API внутренней системы бронирования самого отеля) через определенные интервалы времени. Само резервирование в таком случае происходит с помощью операторов (или колл-центра, или отдельного подразделения на стороне букинг-сервиса). Операторы получают заявку от клиента, резервируют (при возможности) место в отеле (т.е. решают все организационные вопросы с отелем) и отправляют клиенту букинг-сервиса подтверждение/информацию о невозможности бронирования.
— в некоем комбинированном способе с разной степенью автоматизации на разных участках.

1. В Redis лучше представлена работа с коллекциями. Простой пример — инкрементальный счётчик. Вы делаете incrby/hincrby для любого ключа, не заботясь о его наличие в хранилище. В Postgres аналогичная функциональность на основе последовательностей (nextval('foo')) подразумевает, что вы уже создали последовательность 'foo' ранее. Это подталкивает вас на написание процедур, которые перед попыткой изменить счётчик, сначала проверяют его наличие, при необходимости создают его и только потом изменяют. Больше ручной работы.

2. Структуры данных в Redis оптимизированы либо под быстрый поик О(1), либо под компактность и приемлемую произволительность O(N), O(log(N)). Практически всегда получается обходиться простыми или вложенными хеш-таблицами с О(1) или О(n). В Postgres вы практически всегда пользуетесь той или иной разновидностью B/R-tree, GiST/GIN индексов со сложностью O(log(N)(+N)). До версии 8.4, индексы типа HASH в Postgres имели практически схожую с B-tree скорость поиска, поэтому их применение не имело никакого смысла. Сейчас, в версии 9.1, смысла стало больше, но не намного — HASH индексы не поддерживают Write-Ahead Log и при сбоях требуют ручной переиндексации:
"Hash index operations are not presently WAL-logged, so hash indexes might need to be rebuilt with REINDEX after a database crash. They are also not replicated over streaming or file-based replication. For these reasons, hash index use is presently discouraged." http://www.postgresql.org/docs/9.1/static/indexes-types.html

У себя в проектах, я использую и Redis, и Postgres. Первый — как эффективную систему для сбора онлайн-статистики (счетчики-лайки, различные метрики), а второй — как хранилище для пользовательских аккаунтов и контента с его мета-информацией. При этом, наметилась тенденция переносить контент на HBase, оставляя для Postgres только задачи по ACID-обслуживанию операций с пользовательскими аккаунтами.

Критическая цепь
Цель
Цель-2
Теория ограничений Голдратта
Внутри торнадо

Нужен nginx, проксирующий запросы к серверу uWSGI. Все актуальные версии nginx уже имеют в себе модуль для uwsgi, поэтому необходимо просто правильно настроить location'ы