Forem: Owen

Dunena Update: What Happened After I Over-Engineered My First Project 😅

Owen — Sun, 10 May 2026 03:08:24 +0000

Hello again, everyone! It's Owen. 👋

Back in March, I posted about how I over-engineered my first project by building a hybrid Zig + TypeScript cache engine called Dunena, and then deployed it on Kubernetes because... honestly I still don't fully know why. 😅

The response was really encouraging, especially the detailed audit from Kowshik in the comments. Since then I've been heads-down building, and Dunena has grown into something I genuinely didn't expect when I first pushed that repo.

Let me catch you up.

🔢 By the Numbers

The project went from a fun experiment to a proper versioned release. We're now at v0.3.1, with a full changelog, release pipeline, Helm charts, a Python SDK, and more. The codebase has grown across multiple packages in the monorepo and I've learned an embarrassing amount along the way.

🆕 What's New

ARC Eviction Policy

The original Dunena only had LRU. I then added LFU. Now there's a third option: ARC (Adaptive Replacement Cache), implemented directly in the Zig core.

ARC is a hybrid — it watches both how recently and how frequently you access keys, and adapts automatically. The idea is that you don't have to manually tune whether recency or frequency matters more for your workload. The Zig implementation maintains four conceptual zones and adjusts the target balance on each cache miss.

You can pick your policy at startup:

DUNENA_EVICTION_POLICY=arc

Atomic Operations: INCR, DECR, and CAS

One thing I kept running into was needing to update a numeric counter without doing a GET, increment, then SET dance. So I added native atomic increment and decrement to the Zig core. It parses the stored value as an integer, adds the delta, and writes it back — all inside Zig with no round trips.

I also added Compare-and-Swap (CAS) with version tracking. Every cache entry now carries a version number that increments on write. If you want to update a key only when you're sure it hasn't changed since you last read it, you can use CAS:

curl -X PUT http://localhost:3000/cache/mykey/cas \
  -H "Content-Type: application/json" \
  -d '{"value": "new-value", "expectedVersion": 3}'

If the version doesn't match, you get a 409 instead of silently overwriting someone else's change. It's a small thing but it opens the door to building coordination patterns on top of Dunena.

Distributed Locks

Speaking of coordination — there's now a full distributed lock service. Locks are stored in the cache with TTL for automatic release, so a crashed process won't hold a lock forever. You can acquire, release, extend, and force-release locks via the API or CLI:

dunena lock-acquire my-job worker-1 30000
dunena lock-release my-job worker-1

Cache Replication

Dunena now supports write-through replication to secondary instances. When you write to the primary, it fans out the mutation to registered replicas — either synchronously (waiting for confirmation) or asynchronously (fire and forget). This is useful if you want a hot standby or want to keep caches warm across regions.

I want to be upfront: this is not clustering. It's intentionally simple. Dunena still uses SQLite and is still a single-writer system. But for the most common "I want redundancy" use case, this works.

Expanded Database Proxy Connectors

The database proxy originally only supported PostgreSQL, MySQL, and HTTP APIs. It now also supports MongoDB, Redis, and Elasticsearch as backend connectors — all using dynamic imports so they're optional peer dependencies. If you don't install mongodb, the connector just isn't available; nothing breaks.

The pattern is the same regardless of backend: register a connector, then query through it with automatic cache-aside behavior.

dunena db-proxy-register mongo-users mongodb mongodb://localhost/mydb
dunena db-proxy-query mongo-users "users.find"

Python SDK

This was a big one. There's now an official Python SDK for Dunena at sdks/python/, installable as the dunena package. It wraps the full REST API with both sync and async clients (powered by httpx), typed dataclasses for responses, and a clean exception hierarchy.

from dunena import Dunena

with Dunena("http://localhost:3000", token="optional") as client:
    client.set("hello", "world", ttl=60000)
    print(client.get("hello"))  # "world"

    # Durable storage
    client.db.set("user:42", '{"name":"Alice"}', tags=["users"])
    entry = client.db.get("user:42")

The async version works the same way with AsyncDunena and async with. Go and Rust SDKs are still on the backlog.

Health Check Enhancements (responding to Kowshik's feedback!)

One of the things Kowshik pointed out was that production health checks need more than just { "status": "ok" }. The /health endpoint now returns structured diagnostics:

{
  "status": "healthy",
  "version": "0.3.1",
  "uptime": 3600,
  "checks": {
    "zigCore": { "status": "up", "latencyMs": 0.2 },
    "sqlite": { "status": "up", "latencyMs": 1.1 },
    "memory": { "heapUsedMB": 45, "rssMB": 180 },
    "cache": { "entries": 5421, "hitRate": 0.87 }
  }
}

There are also two new probe endpoints that Kubernetes can use properly:

GET /health/live — just returns 200, confirms the process is alive
GET /health/ready — checks SQLite is writable before saying ready

The k8s manifests and Helm chart now point probes at these instead of the generic /health.

k6 Benchmark Suite

Kowshik also asked about load testing. The honest answer in March was "I don't have one." That's fixed now. There's a proper k6 benchmark suite at scripts/bench/ with scripts for basic CRUD throughput, batch operations, and a realistic 80/20 read/write mixed workload.

The thresholds are enforced too: p95 < 10ms for GETs, p95 < 15ms for SETs, and less than 1% error rate. These run as part of the release preparation workflow.

Helm Chart and Terraform

The deployment story got a lot better. There's now a full Helm chart at deploy/helm/dunena/ that exposes all config as values, handles PVC creation, wires up the new health probes, and manages auth token secrets properly.

There's also a Terraform module for deploying to AWS ECS Fargate with EFS for persistent SQLite storage. The EFS approach sidesteps the SQLite single-writer problem cleanly since there's still only one task running against it, but storage is detached from the container lifecycle.

Next.js Documentation

The documentation site (previously a static HTML file served from the server) has been migrated to Next.js with static export. It now has a proper sidebar, dark/light theme, mobile layout, search, and an interactive API explorer powered by Scalar.

🤔 What I've Learned Since March

AI agents got better at the FFI boundary, but still need watching. I still use Claude and Gemini heavily, but I've gotten better at catching when generated code changes a Zig type without updating the corresponding FFI declaration in TypeScript. The rule I now follow without exception: any change to exports.zig gets a diff against ffi.ts before it gets committed. The CI pipeline type-checks this, but catching it manually first saves a confusing crash later.

ReleaseSafe is the right default. This came up in Kowshik's comment and I want to reinforce it. Building Zig with -Doptimize=ReleaseSafe (which is what bun run build:zig does) keeps bounds checking active. Panics become clean process aborts rather than silent undefined behavior. The performance cost is small and worth it.

SQLite is fine, actually. I got a bit anxious after all the comments about scaling SQLite, but for what Dunena is — a single-writer cache layer — SQLite with WAL mode is genuinely excellent. The replication feature lets you propagate writes to replicas. For horizontal read scaling, you disable the DB layer and use only the in-memory Zig cache per instance. It's not Postgres, but it doesn't need to be.

🔭 What's Still Coming

There are a few things still on the backlog that I want to be honest about:

Redis RESP protocol adapter — so Dunena can act as a drop-in replacement for Redis clients without any code changes on the client side. This is a big one and still in design phase.
GraphQL API endpoint — for batched queries, especially useful with the database proxy layer.
OpenTelemetry tracing — alongside the existing Prometheus metrics.
Go and Rust SDKs — the Python SDK was first but there's more to do.
WebSocket integration tests — I'm not going to pretend these are fully covered yet.

🙏 Thanks

Genuinely, thank you to everyone who starred the repo, and reached out. Building in public is kind of terrifying but the feedback has been really useful and pushed the project forward in ways I wouldn't have figured out alone.

🔗 GitHub Repository

🔗 Documentation

If you've got feedback, ideas, or want to contribute — PRs and issues are very welcome. And if you've built something with Dunena or tried the Python SDK, I'd genuinely love to hear about it in the comments. 👇

I Over-Engineered My First Project: Bridging TypeScript and Zig with Bun! 🚀

Owen — Mon, 16 Mar 2026 02:29:06 +0000

Hello, hello! It's me Owen again!

I've been inactive for awhile and thought maybe I should post again (Even if this is my second post fully). Some people say that coding project should start with To-do lists, REST APIs, Generators, etc.

Instead, I decided to dive completely into the deep end. I wanted to build something fast, learn about memory management, and figure out how different languages talk to each other.

So, I built Dunena—a high-performance, hybrid-architecture monorepo. It leverages Bun and TypeScript for the web layer, and delegates heavy CPU tasks to Zig via a Foreign Function Interface (FFI). Oh, and I deployed it on Kubernetes. Because why not? 😅 (But don't worry about that since I'm still new to Docker and Kubernetes.)

🔗 Check out the Dunena Repository on GitHub here!
🔗 Check the documentation here!

Here is a breakdown of what I built, how it works, and the massive amount of things I learned along the way.

🏗️ What is Dunena?

At its core, Dunena is a backend platform designed to handle requests quickly and efficiently. It features routing, WebSockets, pub/sub services, and a caching layer.

But the real magic is under the hood. I wanted the rapid development speed of TypeScript, but I didn't want Node/Bun to get bogged down by heavy computations like compression, bloom filters, or complex stat calculations.

The Tech Stack:

Runtime & Monorepo Manager: Bun 🥟
Primary Language: TypeScript (Strict mode)
High-Performance Core: Zig ⚡
Database: SQLite 🗄️
Deployment: Docker & Kubernetes 🐳 (Again I'm new to this so bare in mind)

🧠 The Architecture

The coolest (and scariest) part of this project is the FFI bridge. Here is how a request goes from TypeScript to near bare-metal execution in Zig.

First, I write the high-performance logic in Zig and export it using the C Application Binary Interface (ABI):

// zig/src/exports.zig
const std = @import("std");

// Exporting a function so Bun can read it via the C ABI
export fn compute_heavy_stats(input_val: i32) i32 {
    // Imagine some incredibly complex, CPU-blocking math here
    var result = input_val * 42; 
    return result;
}

Then, in my TypeScript platform package, I use Bun's native dlopen to load the compiled Zig shared library and bridge the function:

// packages/platform/src/bridge/ffi.ts
import { dlopen, FFIType, suffix } from "bun:ffi";

// Load the compiled Zig library
const path = `../../zig/zig-out/lib/libdunena_core.${suffix}`;

const { symbols } = dlopen(path, {
  compute_heavy_stats: {
    args: [FFIType.i32],
    returns: FFIType.i32,
  },
});

// Now I can call Zig directly from TypeScript!
export function runStats(input: number): number {
    return symbols.compute_heavy_stats(input);
}

When a client hits my Bun server (apps/server/src/index.ts), the platform handles the API routing, hands the heavy computation off to Zig, and returns the result instantly.

🤖 The "AI" Elephant in the Room

I want to be totally transparent: I used AI coding agents to help build this. Using tools like Claude and Gemini was incredible for speeding up the boilerplate, setting up the monorepo structure, and scaffolding the initial file architecture. It felt like having a senior developer sitting next to me typing out the boring stuff.

However... AI agents are terrifyingly bad at manually managing memory across an FFI boundary.

If the AI changed a data type in Zig but forgot to update the exact corresponding FFI definition in TypeScript, the server would just crash with a memory access violation. The AI helped me move fast, but I still had to do the brutal, hair-pulling debugging and fixing. Figuring out how to safely pass pointers, prevent memory leaks, and get Kubernetes to play nice with an attached SQLite volume was all human effort. It taught me not to blindly trust generated code, especially when dealing with low-level systems.

🧗 The Biggest Challenges

1. Managing Memory Across the Void
When you pass data between TypeScript and Zig, there are no safety nets. Bun’s garbage collector has no idea what Zig is doing. Learning how to manually manage memory and use defer statements in Zig was a huge hurdle!

2. SQLite in Kubernetes
Deploying an SQLite database (which is essentially a physical file) attached to a K8s pod via Persistent Volume Claims (PVC) was tricky. It works great for a single pod, but I quickly realized that if I scale this horizontally, I might run into database locking issues.

🚀 What's Next?

This project is far from "finished." I'm currently maintaining this project on my own, but would love to see anyone who'd try and contribute!

Let's Connect!

Since this is my first major project, I would absolutely love any feedback, code reviews, or advice from the community.

🔗 Check out the code on GitHub
🔗 Check the documentation here!

Have you ever tried mixing languages like this or fighting with FFI boundaries? Let me know in the comments! 👇

Elba Lang

Owen — Sun, 19 Oct 2025 04:08:36 +0000

Elba — A modern, statically-typed programming language with multiple compilation backends

GitHub → OwenBellowen/elba

As someone deeply interested in programming languages, compilers, and full-stack systems (yes, that’s me: a student, TypeScript/Zig/Rust dev), I’m excited to introduce Elba — a project I’ve been working on that brings together clarity, performance, and tooling in one language.

Note: I have no intentions yet on making this into a full project. Although I would continue working on this.

🚀 What is Elba?

Elba is a statically-typed programming language designed for clarity, performance, and developer productivity.

It offers:

Static type checking with type inference — so you get all the safety of static typing without always writing verbose annotations.
Generics — write reusable, type-safe code.
Union types, optional types (T?) for null safety — fewer runtime surprises.
A module system, first-class functions, rich arrays, structs with methods.
Multiple backends: AST interpreter for quick prototyping, IR interpreter for faster execution, a C code generator, and an LLVM backend for native performance.
A standard library covering math, strings, and more.

In short: think “modern language with the expressiveness of high-level code” + “compiled speed” + “tooling and REPL to iterate fast”.

✨ Why build Elba?

Because I believe we can push the boundaries of what a new language can offer. Specifically:

Type safety meets productivity: We want the benefits of static typing (fewer bugs) without getting bogged down in ceremony.
Multiple backend flexibility: Sometimes you just want a quick REPL or interpreter; other times you need native speed. Elba gives you both.
For compiler / language-enthusiasts: If you love messing around with languages, building tooling, or exploring alternative type systems (hello Zig and Rust fans), this is a playground.
Modern developer experience: REPL, error-reporting, benchmarking, IR visualization — all included.

🛠️ Getting Started

Prerequisites

Zig (version 0.15.2 or later)
(Optional) LLVM 20 for native backend
(Optional) GCC or Clang for C code generation

Build from source

You can follow the setup on the README.md or below:

git clone https://github.com/OwenBellowen/elba.git
cd elba
zig build
./zig-out/bin/elba --version

Quick Test

./zig-out/bin/elba examples/hello_world.elba
./zig-out/bin/elba repl

Full documentation and more examples live in the examples/ directory and the repo’s docs.

💡 Example code snippet

Here’s a small example showing Elba’s generics + optional types:

// examples/generic_example.elba

fn swap<T>(a: T?, b: T?): (T?, T?) {
    return (b, a)
}

struct Pair<T> {
    first: T,
    second: T,

    fn new(f: T, s: T): Pair<T> {
        return Pair { first: f, second: s }
    }

    fn swap(self): Pair<T> {
        return Pair.new(self.second, self.first)
    }
}

fn main() {
    let maybeNum: i64? = 42
    let maybeNil: i64? = null

    let (x, y) = swap(maybeNum, maybeNil)
    print("x = {x}, y = {y}")

    let p = Pair.new("hello", "world")
    let p2 = p.swap()
    print("swapped: {p2.first}, {p2.second}")
}