eridu-tech — the server-side infrastructure behind your oRPC procedures

[yousif-khalil-abdulkarim]

eridu-tech is a collection of 17 composable backend infrastructure components for TypeScript — caching, locking, event buses, rate limiting, circuit breaking, file storage, and more — built around one idea:

Write business logic once. Replace infrastructure anytime.

It's not an RPC framework and not a replacement for oRPC. oRPC handles the type-safe client↔server contract; eridu-tech provides the reusable server-side infrastructure that lives behind your procedures — caches, rate limiters, distributed locks, event buses, typed config, and resilience primitives. Use them together.

Links: GitHub · Docs · API reference · NPM

---

What problem does it solve?

oRPC gives you beautifully typed procedures and OpenAPI integration. But the endpoints themselves usually need more than type safety — caching to avoid repeated work, rate limiting to protect a route, a distributed lock to coordinate a mutation, an event bus to publish side effects, typed config and env access.

Those pieces usually come from hand-rolled code or disconnected single-purpose libraries, each with its own API and conventions — or a monolithic backend framework that pulls you away from oRPC's model.

eridu-tech sits in the middle:

• Batteries-included primitives that are individually useful and more powerful when composed.
• No lock-in — every component talks to interfaces, not to Redis, S3, or your HTTP layer directly.
• Incremental — start with one component (say, Cache) and add more as you need them.

---

Why I built it

The origin is a concrete frustration: I wanted a NestJS-style backend architecture inside a full-stack framework like Next.js, and it didn't work — NestJS modules are tightly coupled to the NestJS runtime and DI container, so they're hard to reuse anywhere else.

That led to a simple design decision:

Backend architecture should not be locked to the framework that provides your HTTP layer.

So instead of building another framework, I built composable, framework-independent modules that plug into whatever transport you already chose — including oRPC.

---

Design principles

1. Adapter-first — the application owns the architecture

Every module depends on a stable contract; infrastructure differences live behind adapters. A cache is a Cache whether it's Redis, an in-memory store, or MongoDB. Your business logic never imports a vendor SDK directly:

       oRPC (typed contract, transport)
                    │
                    ▼
      eridu-tech Module (Cache, Lock, EventBus, …)
                    │
              Interface / API
                    │
        ┌───────────┼───────────┐
        │           │           │
   Redis         Memory      MongoDB
  Adapter      Adapter      Adapter

2. Composable modules — useful alone, powerful together

Every eridu-tech module should be useful independently, but become more powerful when composed together.

The shared Serde engine shows this best: on its own it's a complete serialization library, but because Cache, LockFactory, and EventBus all accept the same Serde instance, they share one serialization engine — so a Lock object can be stored in the Cache and read back perfectly, with no glue code between components.

3. Frameworks are integration points, not boundaries

oRPC handles the typed boundary; eridu-tech handles the infrastructure behind the handlers:

Frontend / Client
       │
       ▼
     oRPC
       │
       ▼
   eridu-tech
       │
Cache • Locks • Rate limiting • Events • Config • Resilience

4. Unified architecture

Components are independent but share a consistent architecture — no glue code:

• A single serialization engine (Serde) across Cache, LockFactory, EventBus, and more.
• A single execution context — async context propagation (request IDs, user info, transactions) flows through context-aware components.
• Composable middleware — AOP-style retry, timeout, fallback that work across every component.
• Typed domain configuration — ConfigAccessor provides a standardized, type-safe way to read domain configuration variables, with optional schema validation.
• Typed environment access — EnvAccessor provides type-safe environment variable access from any source (process.env, secrets managers, and more), with optional schema validation.

---

Key features

• Switch infrastructure without rewriting business logic — use Redis today, MongoDB tomorrow, no refactoring.
• Test everything without Docker — in-memory adapters + built-in Vitest helpers on every component.
• Bring your own framework — no DI container required; drops into oRPC, tRPC, Hono, Next.js, and more.
• Type-safe from day one — precise generics, rich intellisense, errors caught at compile time.
• Standard Schema validation built in — use Zod, Valibot, or ArkType for compile-time and runtime safety.
• ESM native — works on Node.js, Bun, Deno, and Cloudflare Workers.

---

A quick taste

An oRPC procedure whose handler uses an eridu-tech cache — same API in tests (memory) and production (Redis):

import { oc } from "@orpc/contract";
import { z } from "zod";
import { CacheResolver } from "eridu-tech/cache";
import { MemoryCacheAdapter } from "eridu-tech/cache/memory-cache-adapter";
import { RedisCacheAdapter } from "eridu-tech/cache/redis-cache-adapter";
import { Serde } from "eridu-tech/serde";
import { SuperJsonSerdeAdapter } from "eridu-tech/serde/super-json-serde-adapter";

const serde = new Serde(new SuperJsonSerdeAdapter());

const cache = new CacheResolver({
    adapters: {
        memory: new MemoryCacheAdapter(), // tests
        redis: new RedisCacheAdapter({ database: redis, serde }), // production
    },
    defaultAdapter: "memory",
});

const getUser = oc
    .route({ method: "GET", path: "/users/{id}" })
    .input(z.object({ id: z.string() }))
    .handler(async ({ input }) => {
        const cached = await cache.use().get(`user:${input.id}`);
        if (cached) return cached;

        const user = await loadUser(input.id);
        await cache.use().add(`user:${input.id}`, user);
        return user;
    });

oRPC defines what the API looks like; eridu-tech provides how the backend behaves — caching, rate limiting, locking, events — behind a consistent, swappable interface.

---

Components available today (17)

Category	Components
Foundation	Middleware & AOP · Collection · Serde · Codec · Execution Context · Typed Config Access · Typed Env Access
Storage	Cache · File Storage
Resilience	Circuit Breaker · Rate Limiter · Resilience (timeout/fallback/retry)
Concurrency	Lock · Shared Lock · Semaphore
Messaging	Event Bus

Every component ships with multiple built-in adapters (in-memory, Redis, S3, local disk, and more) and its own in-memory testing adapter.

View all component docs →

---

Getting started

npm install eridu-tech

---

Closing thoughts

oRPC solved the typed-contract problem really well. The question I keep asking is: what do you reach for behind those procedures when the backend grows complex? My answer was a set of composable building blocks with adapters — so you can keep oRPC's model and still get caching, locking, rate limiting, and events without hand-rolling them.

I'd love feedback — especially from people building growing backends with oRPC. What infrastructure do you reach for first? What's missing? I'm happy to discuss trade-offs (abstraction layers aren't free). ⭐ Starring the repo also helps others discover it.