Кеширование привилегий в переменных сессии vs моментальное применение изменений в списке привилегий

Есть одно замечание по поводу кэширования и раздачи привилегий. Реализованный способ предполагает сбор привилегий во время авторизации, сохранения их в сессии и дальше все привилегии авторизированного пользователя берутся из сессии. Чем это плохо? Допустим, моя система критична к правам пользователя и смена прав должна происходить мгновенно, с момента изменения их администратором. Можно считывать их при каждом обращении к странице, но это большая нагрузка...
Я предлагаю реализовать следующий метод. В момент сохранения новых прав пользователя (или администратора, как это у тебя называются все пользователи с правами) привилегии загоняются в массив, сериализуются и сохраняются в базе. При обращении к странице, считывается только эта строка для определения привилегий пользователя и, как следствие, изменения привилегий пользователя будут мгновенно отражаться на его работе.

Не разбирался пристально как реализовано кэширование у тебя в системе. Как разберу - прокомментирую.

По поводу системы где выдача привилегий критична, хотя подозреваю что это провокация

Корпоративный ресурс, например, где осуществляется доступ к конфиденциальным данным компании, с которым также работают партнёры компании (сторонние организации, получающие доступ к ресурсу, например, по ВПН), где оперативность доступа к информации имеет ОЧЕНЬ большое значение (то есть, предположим, счёт идёт на минуты). Партнёры осуществляют доступ к данным на коммерческой основе, то есть ежемесячной абонплатой за аккаунт. И вот, предположим, администратор допустил ошибку в раздаче прав и пользователю стали доступны вместо его данных чужие и в этот момент он залогинился. Задача становится так: надо запретить доступ к не его данным и разрешить к его. По описанной тобой выше схеме (которая применяется сейчас) ему просто ничего не будет доступно пока пользователь не перелогинится (и поверь, не все догадаются это сделать увидев надпись «Данных нет» или «Данные не доступны»), или, в зависимости от реализации, вообще выкинет из системы.
Таким образом оперативность доступа к данным, надёжность работы и юзабилити выходят на первое место. Как следствие, раздача привилегий, в любом направлении, должна быть мгновенной.
И это не притянутая к жизни ситуация а фактически взята из жизни.

Подход немного не с той стороны. Предложенный для примера ресурс не продаёт товар, а предлагает доступ к информации, которая и так принадлежит партнёру, плата берётся за интерфейс доступа к ней. Также, можно добавить и другой, не относящийся к категории товара функционал.
Допустим, корпоратив помимо доступа к данным (визуальное отображение статистических данных), предоставляет сервисы типа: приём заказов, заявлений, получение данных (файлов), отправка данных (файлов), управление (обработка) заказов/заявок, отслеживание обработки (на какой стадии) и т.д. У каждого партнёра есть свой администратор, который управляет привилегиями своих пользователей и может разрешать, либо запрещать доступ к тем или иным сервисам или данным. Внутри компании которая предоставляет услуги доступа и сервисы есть свои пользователи, которым нужен строго индивидуальный набор прав по работе с партнёрами. Кому-то доступны одни сервисы и функциональные возможности, другим другие сервисы и возможности, или в одних и тех же сервисах разные функциональные возможности. Грубо говоря, в системе каждый пользователь имеет свой индивидуальный набор привилегий. На группы пользователи разбиваются по принадлежности к партнёру. Они имеют доступ только к данным своей компании. Пользователи же компании которая предоставляет услуги тоже принадлежат к группе «Своя компания» но доступ к данным у них может быть абсолютный внутри определённого сервиса, или по избранным партнёрам и т.д.. Также возможна дополнительная разбивка на группы (например по отделам внутри компании, или по функциональным возможностям)
Предположим что в системе около 200 пользователей и каждый со своим «характером».
И не забывай, что при всём при этом, как мы предположили, данные имеют высокую степень конфиденциальности и желательно иметь какую-то дополнительную систему контроля привилегий (например, на уровне базы данных триггерами).

Ты меня убиваешь!...
С кэшированием я понял... Это и не основное что меня интересует. Мне интересно как применять твою систему в более крупном проекте чем, допустим, форум.

Пример был приведён как система где моментальная выдача привилегий была бы критична. Оплата доступа лишь дополнительный аргумент и взимается она не за каждый сервис в отдельности, а за доступ к системе в целом. Можем предположить что система бесплатна, но каждый пользователь имеет свой индивидуальный набор привилегий, но в рамках привилегий своей группы. Также, можем допустить что сервисы тоже группируются, то есть система имеет несколько модулей, доступ к которым тоже должен ограничиваться.

Вот я ещё раз перепрочитаю статью, на всякий случай, потом сформулирую... То есть сделаю ещё одну самостоятельную попытку осилить.
А вкратции, не очень понятно как работать с группами в приведённом примере, как сделать так чтобы пользователь одного партнёра никак не унаследовал права другого, то есть не причислился к двум этим группам...