DEV Community: Eyosias Negash

Three services and nothing to store

Eyosias Negash — Fri, 30 Oct 2026 12:18:44 +0000

Originally published at eyosias.me. This is a chapter in the Ivyk8 series.

Last time: I cut a flagship-platform plan down to three stateless TypeScript services and five written decisions. This chapter is the result: what runs, how a request travels, and what keeps it safe.

TL;DR

The app reads an Android money manager’s backup from the user’s Google Drive and turns it into reports.
Three services: a static React dashboard, a public back end (drive-sync-service) and an internal calculator (analytics-service).
A report request is a pure function of (backup, timezone, rate overrides). Change the timezone and the same request runs again with new parameters. Nothing is stored.
The security model is mostly subtraction: tokens never reach the browser, the calculator is unreachable from outside, and every container runs unprivileged.

The shape

 Browser ──► Ingress (Traefik)
              ├── /      ──► web-dashboard        React app, served by nginx, static only
              └── /api   ──► drive-sync-service   public API (a BFF)
                               │  Google sign-in, Drive read-only
                               │  encrypted cookie session
                               ▼
                             analytics-service    reachable inside the cluster only
                               │  validate → index → pure report functions
                               ▼
                             ECB daily exchange rates (+ fallback)

A BFF (backend for frontend) is a server that exists to serve one front end. Here it owns everything that touches Google, so the browser never does.

Service	Owns	State	Public?
`web-dashboard`	the UI	none	yes, `/`
`drive-sync-service`	sign-in, token refresh, folder choice, listing backups, choosing which bytes to analyse	an encrypted cookie	yes, `/api`
`analytics-service`	validation, business rules, exchange rates, every number on screen	an in-memory cache	no

A shared packages/contracts package holds the request and response types, so a change to a report’s shape fails the build in both services.

Opening a report, one hop at a time

Say you open the balances page.

The browser calls GET /api/backups/:fileId/balances with a timezone and optional rate overrides.
drive-sync decrypts the session cookie and refreshes the Google access token if it has expired. If the refresh token is dead it answers 401 REAUTH_REQUIRED and the UI shows a “Reconnect” link.
It checks the file is in the folder you chose. A file ID from anywhere else gets a 404. That check is the line between “your backup folder” and “any file this token could see”.
It builds the dataset key: sha256(user id, file id, Drive md5). Two users never share a cache entry, and an edited file gets a new key.
It asks analytics for the report. If analytics answers 404, the dataset isn’t loaded: first open, evicted, or the pod restarted. drive-sync then downloads the backup (with a size limit enforced up front and while streaming), PUTs it to analytics, and retries once.
Analytics computes the report from the dataset, timezone and overrides, and returns the numbers with the rates it used and any warnings.

The 404-then-upload dance is the design in miniature. Analytics holds parsed backups in an in-memory LRU cache, and the cache is allowed to be wrong. When it’s empty, it gets refilled. That is why a pod can be killed at any time without anyone noticing, and why there is no database to back up.

It is also why “change the timezone” or “override this exchange rate” needs no endpoint of its own. It is the same request with different query parameters.

Security: mostly subtraction

Most of the model is things the system doesn’t have.

Tokens never reach the browser. The session is an encrypted cookie that only drive-sync can open, and Google access is limited to the drive.readonly scope.
Only named reports pass through. drive-sync forwards a report name to analytics only if it is in a fixed allowlist (REPORTS). A new report is invisible to the outside world until someone adds it there.
Default deny. Every namespace starts from a deny-all NetworkPolicy, and each allowed path (ingress to dashboard, ingress to drive-sync, drive-sync to analytics) is written explicitly.
Restricted Pod Security. The namespace enforces the restricted profile: no root, no privilege escalation, dropped capabilities.
Small images. The Node services run on distroless images (no shell, no package manager, non-root). The dashboard uses nginx-unprivileged. The root filesystems are read-only.
A smoke test proves the claim. The deploy check requests analytics from outside the cluster and expects it to fail. A policy nobody tests is a hope.

The calculator

analytics-service is where the rules live, so it is where bugs will live too. Its shape keeps them findable:

Validate once. A backup is checked against a schema with ajv on upload. Everything after that trusts the shape.
Reports are pure functions. Input is the dataset, a timezone and rate overrides. Output is numbers. There is nothing to mock and nothing to reset between tests.
Time is bucketed by the user’s timezone, with weeks starting on Monday. A transaction near midnight lands in the day the user would call it.
Rates degrade gracefully. ECB rates are cached and served stale if a refresh fails. A user override wins over any fetched rate. A currency with no rate at all is reported as “unavailable”, not guessed.
Problems become warnings, not failures. A report with one unconvertible transaction still renders, and says so.

What it could do at launch

Sign-in, a folder picker, a backup list, a transactions table, balances and net worth, income and expense, and the Trends charts. Later chapters add budgets, a projection, tags and custom reports.

How it gets onto a cluster

make up creates a local k3d cluster (Kubernetes in Docker) and deploys everything with kustomize. Overlays for local, CI and a multi-node cluster differ in small ways, such as which ingressClassName the Ingress objects use. There is also a CI pipeline that tests, scans and signs images. At this point it is written but has not run once.

A small question worth recording

kubectl port-forward svc/traefik 30080:80 reaches the container’s port 8000, not 80. The Service’s port 80 maps to a named targetPort, and the Traefik chart binds a non-root port because it runs unprivileged. The “80” is the Service’s, not the container’s.

Takeaways

If a result is a function of its inputs, don’t store it. Recomputing from (backup, tz, rates) removed the database, the migrations and every “which copy is right” question.
Let the cache be wrong. A cache that can be empty at any time, with a defined refill path, turns pod restarts into non-events.
Prove the negative. “Analytics is internal” is only true if a test tries from outside and fails.
Allowlist what a public server forwards. An allowlist fails closed; a blocklist fails whenever you add something.

What’s next

The next chapter moves this off my laptop’s local cluster onto three machines at home. It did not go the way the diagram suggests.

The story continues as the work does.

Source: github.com/eyosias-k-negash/ivk8. First commits: e1d849a, 65bac77.

Previous: Chapter 1, From a phone app to a cluster

From a phone app to a cluster

Eyosias Negash — Thu, 29 Oct 2026 21:21:27 +0000

Originally published at eyosias.me. This is a chapter in the Ivyk8 series.

TL;DR

Ivyk8 is Ivy + k8s: a read-only desktop dashboard for the backups my phone app writes to Google Drive.
The first blueprint was a flagship platform: Postgres with replicas, Redis, a service mesh, GitOps, canaries. A critique of it said it was about 18 months of work for a team.
On Oct 1 I cut it to three stateless TypeScript services, Kubernetes for delivery, and five written decisions (ADRs).
This is part 1 of a series. Parts about each feature and each outage follow.

Where it starts: a phone app I couldn’t leave alone

Ivy Wallet is an open-source money manager for Android. Its owner archived it on Nov 5, 2024. I wanted to keep using it, so I forked it as Ivy Wallet+ and added what I was missing.

The additions, in the order I made them in late August:

Photo and audio attachments on transactions.
Transaction location: coordinates and a place name, a Room (Android’s SQLite layer) migration, and a button that opens the place in a maps app.
Balance at day: tap a date in the history and see each account’s balance on that day.
SMS auto-fill. The app listens for bank SMS on a chosen SIM, parses the amount, balance, date and description with per-bank regex rules, and raises a notification that opens a pre-filled transaction. Rules import as JSON. I wrote rule sets for four banks and a mobile-money wallet.
A wrapped reports filter in place of horizontal scrolling, and a rebrand to Ivy Wallet+ with its own package name and logo.

None of that is this blog’s subject. It matters because of what it did to the data. The phone now captured more than before, and a phone screen is a poor place to study years of transactions.

The gap

Ivy Wallet+ already writes its backups to Google Drive. That file is the whole interface between the phone and anything else. So the idea was small: read the backup, show it on a desktop screen with charts the app can’t draw, and see trends, averages, and projections of expenses and incomes.

The first blueprint was too big

I started where an ambitious person starts, with a prompt for a “top 1% flagship project”. The first blueprint had:

a Kotlin sync client and a Go sync API;
a currency service and a report worker;
Postgres with read replicas, and Redis as both cache and queue;
Istio, Argo CD, Argo Rollouts, KEDA, SOPS and a full observability stack.

I asked Claude Code to critique it before building anything. This is where the pair worked well: the critique was blunt and I kept it.

“Roughly 18 months of work for a team.”

It also found specific faults:

Redis as cache and queue is a contradiction. A cache wants allkeys-lru (evict anything under memory pressure). A queue needs noeviction (never lose a job). One instance can’t be both.
Read replicas break read-your-writes. A sync client that uploads and then reads back can see old data.
A hand-rolled Postgres StatefulSet “signals junior K8s judgment”. Use an operator, or don’t run a database.
No identity layer. Nothing said who the user was.
“Cosign signing without admission verification is security theater.” Signed images mean little if the cluster never checks the signatures.

The last point is worth a dry aside. It’s still partly true of this project today: the release workflow signs images, and nothing in the cluster verifies them yet. The critique named the gap before I built it. Closing it is on the list.

The cut

I cut in two stages.

The MVP prompt kept core Kubernetes and a basic CI pipeline with static scanning. GitOps, canaries, observability, KEDA and signing went on hold.

The final cut, Oct 1, went further. I wrote it down as five architecture decision records (ADRs), short files that say what was decided and what it replaced:

ADR	Decision
0001	Three stateless TypeScript services: `web-dashboard`, `drive-sync-service` (the public back end for the dashboard) and `analytics-service` (internal). No Postgres, no Redis. It supersedes the earlier scaffold.
0002	Sessions live in an encrypted cookie, so the services hold no session store.
0003	Google Drive access is limited to the `drive.readonly` scope. The app can’t change a backup even if it were compromised.
0004	Kubernetes is the only delivery path: k3d (Kubernetes in Docker) locally and in CI, no docker-compose.
0005	Exchange rates come from the ECB, with a fallback source for currencies the ECB doesn’t publish.

The reasoning behind 0001 is the part to keep. The analytics are computed in memory from one file. Timezone and rate overrides are request parameters. Nothing needs to persist between requests, so nothing gets a database. On a cache miss, drive-sync re-uploads the backup to analytics. That is a feature, not a shortcut: stateless services can be killed, replicated and rolled without ceremony. I did not know yet how much I would lean on that.

The goal

One sentence in the repo says what I was after: built, secured, tested and delivered the way a production product would be. The product is a personal dashboard for one user. The practice around it is the point: tests that gate merges, image scanning, signed releases, rollouts on a real cluster.

That decides how the series is told. Features are chapters. The cluster misbehaving is its own kind of story, and those get shorter posts of their own.

What it taught me

Ask for the critique before the code. An hour of being told the plan is theater was cheaper than 18 months of finding out.
Statelessness is a decision you pay for once. Dropping the database removed whole classes of work: migrations, backups, replicas, failover.
Write the decision down while it is fresh. The ADRs are why I can still explain, weeks later, why there is no Redis.

What’s next

The next parts cover the dashboard’s first real features and the move from a local k3d cluster onto three machines at home. That second move did not go smoothly, and it is the source of the stranger posts.

The story continues as the work does.

Source: github.com/eyosias-k-negash/ivk8. Decisions: docs/adr/0001–0005.

Next: Chapter 2, Three services and nothing to store