Your Develit architecture · Nuxt Interview Prep

From the "What I did at Develit" part of your Conrad DevOps note. Expect "tell us about your current architecture" early in the interview: this page is the material for a two-minute answer and the follow-ups.

Know

Shape: isolated services as separate Workers (banking, crypto wallet, AML, business, RBAC, auth, notifications, currency feed, documents), each its own npm package, never calling each other; a core app whose gateway orchestrates them.
Communication: service bindings and Workers RPC: no public URLs, no external network hop.
State and work: KV for read-heavy, slightly stale data such as exchange rates; Durable Objects for idempotency; Workflows for durable multi-step processes; Queues for background work.
Front end: micro-frontends (admin, app, landing page) extending shared Nuxt UI layers.
Why it fit: many small projects with a few bigger ones, not one huge app, so small independently owned services made sense.
A whole e-shop on Cloudflare: possible, Shopify's Oxygen runs on Workers; a Hono gateway Worker routing over service bindings to per-domain Workers with their own D1, repo and logging, Queues and Workflows for long work, Hyperdrive for Postgres; limits are CPU time per request, no long-lived connections, D1 size, and vendor commitment.
Contrast with Conrad: no Redis there, because the data was personal, financial and behind a login; Redis is central at Conrad, because the catalogue pages are shared by large groups of visitors.

Exercise

Record a two-minute answer to "tell us about your architecture", then a one-minute version.
Prepare one concrete story: a problem you solved there (an idempotency bug, a slow service, a shared-layer change that broke a consumer), with what you measured and what changed.

Be able to say

Be able to say· Tell us about the architecture you worked on at Develit.

"A financial platform built entirely on Cloudflare. The backend was a set of isolated Workers services, such as banking, crypto wallets, AML, RBAC and auth, each published as its own package, which never called each other. A core application's gateway orchestrated them through service bindings and RPC, so calls never left Cloudflare's network. Exchange rates were cached in KV, idempotency was enforced with Durable Objects, and long processes ran on Workflows and Queues. The front end was several Nuxt apps extending shared UI layers. I have also run Docker, Kubernetes, Terraform and Redis on earlier projects, so Conrad's stack is familiar from that side."

Be able to say· Why no Redis at Develit, but Redis at the heart of Conrad?

"At Develit almost nothing was shared between users and nothing could be stale, since these were balances behind a login, so a shared cache had little to store and real risk; the bit of shared data lived in KV. Conrad's catalogue is the opposite: public pages that are the same for big groups of visitors and get heavy traffic, so rendering each variant once a minute and serving it from Valkey saves most of the work. Same rule in both places: cache what is shared and tolerates staleness, never what is personal or must be exact."

Your notes

Open in Notes

Nothing yet. Notes filed here show up on this page and the section overview.