Modern SaaS platforms like Shopify allow multiple staff members to manage stores with fine-grained access controls. Admins, managers, support teams — each role needs the right balance between access, security, and performance.
When designing such a system, two questions immediately appear:
- 1. How do we authenticate staff (who are they)?
- 2. How do we authorize them (what can they do)?
And the big architectural question behind all of this:
Where do we store and fetch those permissions — Redis, SQL, or MongoDB?
In this post, we'll explore how Shopify-like platforms structure staff permissions, compare three backend options —Redis-only, Postgres/MySQL + Redis, and MongoDB + Redis — and finish with a practical recommendation based on cost, performance, and durability.
⚙️ How Staff Authentication & Authorization Work (Shopify Style)
- • Authentication (AuthN) confirms identity — typically via password, OAuth, or SSO.
- • Authorization (AuthZ) defines access — via roles and permissions.
- • Audit trail tracks every permission or role change.
Shopify applies Role-Based Access Control (RBAC) layered with Store Scope. Each staff user belongs to one or more roles that define permissions (e.g., read_orders, write_products).
🧱 Design Requirements
When building this for your own SaaS or retail platform, these are your non-negotiables:
🚀 Option 1: Redis-Only
✅ Pros
- • Ultra-fast reads (sub-millisecond)
- • Simple — no joins or ORM needed
- • Great for prototypes or edge-cache style setups
❌ Cons
- • Durability risk (Redis is memory-first)
- • No query power — can't easily list "all staff with X permission"
- • Higher memory costs at scale
- • Recovery complexity if data lost
🧩 Option 2: Postgres/MySQL + Redis (Recommended)
✅ Pros
- • Full durability + ACID transactions
- • Easy to audit and query
- • Low-latency reads (cached)
- • Cost-efficient (Redis only holds hot data)
❌ Cons
- • Cache invalidation logic required
- • Slightly more complex architecture
🌿 Option 3: MongoDB + Redis
✅ Pros
- • Flexible schema — evolve quickly
- • Ideal for denormalized permission models
- • Easier to embed custom scopes per store
❌ Cons
- • Harder to run relational queries
- • Multi-document transactions slower
- • More ops complexity (clusters, sharding)
💾 Schema Example (Postgres + Redis)
CREATE TABLE roles ( id UUID PRIMARY KEY, name TEXT NOT NULL ); CREATE TABLE permissions ( id TEXT PRIMARY KEY ); CREATE TABLE role_permissions ( role_id UUID REFERENCES roles(id), permission_id TEXT REFERENCES permissions(id), PRIMARY KEY(role_id, permission_id) ); CREATE TABLE store_role_assignments ( store_id UUID, user_id UUID, role_id UUID REFERENCES roles(id), scope JSONB, PRIMARY KEY(store_id, user_id) );
Redis Key Pattern
store:{storeId}:user:{userId}:permsJSON Value Example
{
"permissions": ["read_orders", "write_customers"],
"version": 3,
"expires_in": 300
}💰 Cost & Performance Snapshot
| Option | Durability | Read Speed | Query Power | Cost | Recommended For |
|---|---|---|---|---|---|
| Redis-only | Low | ⚡⚡⚡ | 🔸 Minimal | 💸 High (RAM) | Prototypes |
| Postgres/MySQL + Redis | High | ⚡⚡ | ✅ Strong | 💰 Balanced | Production |
| MongoDB + Redis | High | ⚡⚡ | ⚙️ Medium | 💰+ | Flexible schemas |
🔒 Security Tips
🧭 Final Recommendation
✅ Postgres + Redis = Durability + Performance + Cost Efficiency
Together, they form a scalable, Shopify-grade permission backbone.
🧱 MBTEdge Takeaway
Designing staff authorization isn't about the fastest tech — it's about balancing correctness, consistency, and cost.
Author: MBTEdge Engineering Team
Tags: #Shopify #Redis #Postgres #MongoDB #Architecture #MBTEdge #SaaS #AuthZ #RBAC