Forem: MD RASHEDUL ISLAM

We almost spent £180/month on Redis. We spent £40 instead.

MD RASHEDUL ISLAM — Sat, 23 May 2026 23:52:41 +0000

by Rashed

We had a number in our heads: managed Redis, smallest HA tier, maybe $70 a month. We needed a Redis-class store for coordination primitives — JWT denylist, rate-limit counters, idempotency keys, distributed locks — and it had to survive a node dying, because some of those primitives sit on the money path. So we went to provision it.

The console had a different number. Memorystore for Redis Standard — the tier that actually gives you a high-availability replica — starts at 5GB. Not 1GB. The smallest HA config you can buy is $234/mo. We needed about 1.25GB. We were looking at paying 4.5× for capacity we'd never touch, purely to get the replica.

That gap between the number in our heads and the number on the screen is the whole story. We ended up on Memorystore for Valkey at $51/mo, with HA, and the migration cost us zero lines of code. Here's how we got there.

What the store is actually for

None of this matters unless the store earns its keep, so: what runs on it.

Four things, all of them coordination rather than data-of-record:

Idempotency keys. Money-path endpoints (orders, payments, refunds, captures) dedupe retries against keys held here. If TanStack Query retries a payment POST on a network blip, the second request finds the key and replays the first response instead of charging twice.
JWT denylist. Revoked tokens get checked against this on the way in.
Rate limiting. Per-business counters.
Locks. Short-lived coordination for workers that mustn't double-act.

Three of those four are either security or money. That's why "no HA" was never really on the table for go-live — if the store vanishes mid-incident, the idempotency guarantee vanishes with it, and the failure mode is a double charge, not a slow page. We do fail open on lookups to stay available, bounded by the access-token lifetime, but the store being up is the thing we're paying for.

So we needed HA. That's the constraint that made the pricing matter.

The number we had wrong

Here's the thing worth saying plainly, because it's the actual lesson: we quoted the price from memory and the memory was wrong.

We'd assumed Memorystore for Redis "Standard 1GB" was a thing that existed at roughly $70/mo. It isn't. On GCP, the Redis Basic tier gives you 1GB but no replica — no HA at all. The moment you want a standby replica, you're on Standard, and Standard has a 5GB floor. There is no 1GB HA Redis. The cheapest HA Redis you can provision is 5GB at $234/mo.

We only found this by opening the console for our actual region (europe-west2) and trying to build the thing. Every back-of-envelope number we'd written in the planning doc was wrong, because we'd been pricing a configuration that doesn't exist.

These are the numbers we actually saw, verified in the console on the day we provisioned:

Config	Monthly	HA	Notes
Redis Basic, 1GB	$39 (£30)	No	Cheapest, no replica at all
Redis Standard, 5GB (min)	$234 (£180)	Yes	4.5× our actual need
Valkey, pico + 1 replica	$51 (£40)	Yes	What we shipped for go-live
Valkey, pico, 0 replicas	~$26 (£20)	No	What we run in the test phase

The shape of the table is the argument. Redis Basic is cheap but gives us nothing we can launch payments on. Redis Standard gives us HA but bundles it with 4GB of RAM we will never address. Valkey gives us HA at a size that matches the workload.

Why Valkey, specifically

Valkey is the open-source fork of Redis that the Linux Foundation picked up after Redis changed its license in 2024. On GCP it shows up as Memorystore for Valkey, and the reason it was an easy call comes down to four things.

The migration was free. Valkey is wire-compatible with Redis 7.2. Our client is ioredis, and ioredis does not know or care whether it's talking to Redis or Valkey — same protocol, same commands, same connection code. We changed the host it points at. That was the entire code change. There's a version of this post where switching datastores is a two-week migration; this was not that.

The license is actually open. Valkey is BSD-3-licensed. Redis moved to a source-available license (RSALv2 / SSPLv1). For us this is a portability question, not an ideology one: if we ever leave GCP, an open-source-licensed store is one fewer thing tying us to a vendor's managed offering. It costs nothing today and buys optionality later.

The networking is the modern path. Memorystore for Valkey connects over Private Service Connect into the platform VPC, rather than the older VPC-peering model. PSC doesn't consume an IP range from our network and gives finer-grained access control. It's a one-time service-connection setup, about fifteen minutes, documented in our runbook. We'd rather be on the path Google is investing in than the one they're winding down.

HA at a sane size. This is the one that started the whole thing. Valkey lets us provision a small instance (a ~1.25GB pico) and separately choose to add a replica. The HA decision is decoupled from the capacity decision. With Redis Standard those two are welded together at 5GB.

The pre-launch trick

One detail that saved us money without costing us anything: the replica is a toggle, so we don't pay for it before we need it.

In the test phase, where there are no real payments and a node dying means a developer reruns something, we run Valkey with zero replicas at about $26/mo. The day before we start processing live payments, we bump it to one replica and it becomes $51/mo HA. Same instance, same data model, same connection string — one setting.

We're not paying for a standby to protect test traffic that doesn't need protecting. The HA cost lands exactly when the thing it protects goes live, and not a month earlier.

What we picked, what we rejected, why

We picked Memorystore for Valkey, pico size, one replica, europe-west2, over Private Service Connect — $51/mo, HA, wire-compatible with our existing Redis client.

We rejected Redis Basic 1GB ($39/mo). It's the cheapest line on the table and it was never viable, because it has no replica. Saving $12/mo to run our idempotency and denylist on a single node with no failover is a false economy the first time that node restarts during a payment.

We rejected Redis Standard 5GB ($234/mo). This is the option we'd have sleepwalked into if we hadn't opened the console. It's a perfectly good product; it's just sized for a workload four and a half times ours, and you can't buy it smaller. Paying $183/mo more than Valkey for 4GB of RAM we'll never address is the definition of overprovisioning.

What we gave up by choosing Valkey: Redis is the older, more battle-tested managed product with a deeper operational track record on GCP. Valkey-on-Memorystore is newer. We're betting that wire-compatibility plus an open license plus a managed SLA covers the maturity gap for a coordination store — and that bet is much easier to make when the thing speaks the exact same protocol, so reverting would also be a one-line change.

The takeaway

The lesson isn't "use Valkey." The lesson is the thing that nearly cost us $183 a month: don't quote cloud pricing from memory — open the console for your actual region and try to build the actual thing. Our planning number was off by a factor that mattered, not because we were careless but because the tier we assumed existed simply doesn't. Pricing pages have floors, minimums, and tier boundaries that don't show up until you're in the provisioning flow.

Two questions worth asking before you provision any managed datastore. First: do you actually need HA, or are you about to pay for a replica to protect traffic that can tolerate a restart? For us the answer was yes, but only on the money path, and only at go-live. Second: is your capacity floor set by your workload or by the vendor's smallest HA tier? If it's the vendor's, there's usually a wire-compatible alternative that lets you size HA and capacity independently.

We'll come back to the things this store actually powers in later posts — the idempotency middleware on the money paths is its own story, and so is the JWT denylist. This one was about the bill. We almost paid £180 a month. We pay £40.

One backend, four products: why we bet on platform-per-brand

MD RASHEDUL ISLAM — Sat, 23 May 2026 04:06:24 +0000

by Rashed

We shipped an auth bandaid at 2am. Cookies wouldn't flow between platform.ginilab.com and our gateway, which was running under a different registrable domain. Browsers blocked them, correctly. The bandaid that unblocked the demo was a 5-minute bearer token held in a Zustand store on the frontend, attached by hand to every request. It worked.

Within 24 hours we'd shipped four PRs of cookie-domain workarounds. Then someone asked the obvious question: "why isn't api.ginilab.com just another hostname on the same gateway?" It was. We were deep into a problem we'd solved in a single DNS record.

That bug — cookie-domain mismatch in a multi-brand platform — is the one-paragraph version of why this post exists.

One caveat before we go further. v3 is in staging. It's not yet processing live payments. 300+ restaurants run on our legacy PHP/MySQL stack today, and the cohort migration hasn't started. What follows is the architecture we bet on and the pain we hit getting here, not a victory lap. If you want a "we scaled to a billion requests" story, this isn't it. If you want an honest mid-migration account from a small team, read on.

What "platform-per-brand" actually means

Ginilab is one backend platform that runs four products. Tomafood is restaurant ordering, with 300+ restaurants live on the legacy stack and the full rewrite to v3 in progress. CloudPOS is a POS for non-food retail. iSchool is school management. Ecommerce is generic ecommerce. Tomafood is the full rewrite. The other three consume shared services via REST or SDK. They aren't separate codebases. They aren't separate backends. They're different products mounted on the same platform.

This is unusual. Most SaaS teams either build one product and stay there, or build separate platforms per product when product two arrives. The shared-platform-across-products shape is the third path, and it has a tax: every architectural decision has to assume more than one consumer, more than one brand, more than one domain. The tax shows up early and never goes away.

We took the tax on purpose. We knew CloudPOS and iSchool were coming. Without that, this would have been overengineering.

[INSERT DIAGRAM 1 HERE — architecture sketch: four products on top, shared multi-hostname gateway in the middle, shared services below keyed by business_id + app_id, Tomafood-only restaurant-service off to the side.]

We rejected the obvious answer twice

The obvious answer when a second product appears is to fork. Take the codebase that works for product one, copy it, change the domain, run a second backend. Engineers know how to do this. It feels safe.

We rejected it twice. The first time was when CloudPOS came online and the temptation was to fork Tomafood's auth service and run it as a second backend behind the POS product. The second time was when iSchool was scoped and the temptation flipped: extract microservices per product, one stack per vertical. Both options were wrong for the same underlying reason. A customer who orders on Tomafood and later signs up for CloudPOS should be the same identity. Forking the auth service means reconciling those identities later. Per-product microservices means reconciling them four times.

The version that doesn't require reconciliation is one auth service, multi-tenant by design, with every shared service carrying both who the business is and which product they're using.

The design rule that makes it work

Every shared service in the platform — auth, addresses, payments, notifications, gateway — carries two identifiers on every query:

business_id is the specific business (UUID).
app_id is which product they're using: tomafood, cloudpos, ischool, and so on.

Not restaurant_id. There is no restaurant_id column anywhere in a shared service. restaurant_id is a Tomafood-only concept that lives only in the Tomafood product service.

The pair flows through JWT claims and is enforced at the repository layer. We say this in the CLAUDE.md at the root of the repo about as bluntly as we can:

Shared services NEVER use restaurant_id — always business_id + app_id.
Repository enforces WHERE business_id = ? on every query.
JWT claims include businessId + appId.

In practice that means a row in auth_db.users doesn't know what a restaurant is. It knows it belongs to a business, and the business runs on an app. A row in restaurant_db.recipes does know what a restaurant is, because restaurant_db belongs to Tomafood and restaurant_id is meaningful there.

The boundary is consistent. Shared services see businesses. The Tomafood product service sees restaurants. That sentence took us a long time to write down, and longer to enforce.

[INSERT DIAGRAM 2 HERE — decision tree: shared service? then business_id + app_id. restaurant-service? then restaurant_id is fine. Neither? then you're in the wrong file.]

The multi-brand pain, made concrete

The cookie story from the opener is what happens when "multi-brand" stops being an abstract design rule and becomes a Tuesday. Each restaurant on Tomafood can run on its own white-label domain — their brand, their registrable domain. The platform has its own brand. The gateway has to accept cookies from all of them.

The first version of the cookie-domain helper was a security hole. It checked host.includes('ginilab.com') to decide whether to set the cookie's domain attribute. A lookalike host like ginilab.com.evil.example would have passed that check. The second version checks suffix-with-leading-dot:

// packages/shared/src/cookies/pick-domain.ts
export function pickCookieDomain(
  origin: string | undefined
): string | undefined {
  if (!origin) return undefined;
  const host = new URL(origin).hostname;
  if (host.endsWith('.ginilab.com')) return '.ginilab.com';
  // ... plus one branch per brand registrable domain
  // Lookalike-domain defence: must end with the LEADING dot,
  // not just contain the string.
  return undefined;
}

A handful of lines. They exist because we have more than one brand on one platform. If we'd had one brand, this would have been a hardcoded constant. If we'd had four separate backends, each one would have hardcoded its own constant, and the bug would live in four places.

This is the smallest, ugliest example of the platform-per-brand tax. There are larger ones. They all have the same shape: a thing that would be a constant in a single-brand world becomes a function in a multi-brand one. The function is the cost.

What we picked, what we rejected, why

We picked one backend platform, multi-product, multi-brand. Shared services keyed by business_id + app_id. The Tomafood-only product service keeps restaurant_id. JWT carries both identifiers. The same gateway is exposed under per-brand hostnames so cookies flow.

We rejected one codebase per product — four backends, four auth services, four databases. This is the standard SaaS path and most teams' default. We rejected it because the products share customers and the reconciliation cost compounds. A user who shops on Ecommerce and orders on Tomafood and whose kid is on iSchool is one human. Four backends would turn that human into four accounts with four passwords and four address books, held together by sync code. We would be writing and maintaining that sync code for years.

We rejected microservices-per-product from day one. Per-vertical stacks, one platform-org per product. We rejected this because we're a small team and the operational surface scales with services rather than users. Splitting before a second consumer exists for any given surface is premature. Our restaurant-service today is a deliberate monolith — it contains menu, orders, kitchen, tables, drivers, reservations, and reviews in one deployable. We will split a surface out the moment a second consumer (CloudPOS, iSchool) needs that surface, and not before.

We gave up the freedom to ship a product-specific schema change without thinking about other products. Every shared schema change has to consider all current and plausible future consumers. That slows down week-to-week work. The bet is that it speeds us up over the lifespan of the platform.

What we got is more boring than it sounds: one auth service, one identity model, one set of secrets to rotate, and a single place to fix every helper.

The takeaway

Platform-per-brand is a bet on product-multiplication. We made it because we knew CloudPOS and iSchool were coming. If you only ever ship one product, this is pure overhead. Every shared-service decision costs more than it would in a single-product codebase, and you get none of the payoff. If you'll ship two, the difference is one team versus four. If you'll ship four, there is no version of this where fork-and-clone stays survivable.

Two questions worth sitting with before betting the same way. Do you know what product two looks like? Does it share customers with product one? If both answers are yes, the platform shape pays off. If either is no, it's overhead.

We'll come back to specific pieces of this in later posts — the idempotency middleware on money paths, the multi-zone CDN purge, the Valkey vs Redis pricing fight, the strategic monolith. Each is its own story. This post is the foundation. Every later decision in the series only makes sense because the platform shape was already chosen.