From laptop to production

The default assumption for production APIs is a database server, a container orchestrator, and a team to operate them. For many workloads this is the right answer. But for many others, it's an expensive one that goes unquestioned.

We deployed a 13-entity federated API with event sourcing to AWS Lambda. No database server. No Kubernetes. No container registry. The entire system is a 3.8MB binary that cold-starts in 57 milliseconds, writes to a file system, and costs fractions of a cent per thousand requests.

The architecture

The stack is three components. A Rust binary compiled for ARM64, an EFS file system mounted into the Lambda, and an API Gateway routing requests to the function. The binary contains 13 REST endpoints for writes, 13 GraphQL endpoints for reads, and 19 federation resolvers that join across entities.

The storage layer is merkql, an embedded event log with Kafka-compatible semantics—topics, partitions, consumer groups, append-only writes—backed by files instead of a broker cluster. Every write is content-addressed by SHA-256 and verifiable against a merkle tree. The event log supports temporal queries: read the state of any entity at any point in time.

What we measured

We ran four test scenarios against the deployed API: warm single-user CRUD, federated GraphQL queries, concurrent load with 10 users, and write contention with 5 concurrent writers to the same entity type.

The latency is dominated by EFS I/O, not the application. REST writes take ~100ms because each write fsyncs to EFS for durability. GraphQL reads are slightly higher because they replay from the event log. Federated queries that resolve across three entity types—farms, coops, hens—still complete in 205ms at the median.

Under concurrent load, the numbers hold. With 10 simultaneous users mixing reads and writes, the overall median stays at 192ms.

The Lambda init duration is 57 milliseconds. That's the time for the runtime to load and start a 3.8MB Rust binary containing 13 entities, 19 resolvers, and the complete event-sourcing storage engine. The remaining ~850ms of the end-to-end cold start is VPC ENI attachment and EFS mount—infrastructure overhead, not application code.

Memory usage peaks at 22MB. We allocated 512MB. The binary could run comfortably at 128MB.

What it costs

Lambda pricing is per-request and per-millisecond of compute. At 512MB with a median billed duration of ~100ms, each request costs approximately $0.0000008. A million requests costs $0.84 in compute plus $0.20 in API Gateway fees. The EFS storage costs $0.30/GB-month. At idle, the system costs nothing.

Compare this to the minimum viable production infrastructure for a traditional deployment: a managed database ($50–200/month), a container host ($20–100/month), load balancer ($18/month), and the operational overhead to keep them running. The serverless deployment eliminates all of these for workloads that fit the model.

Where it breaks

This architecture has a hard constraint: single-writer. The event log uses file-level locking (flock) for write exclusion. On EFS, concurrent writers serialize correctly but queue behind the lock, and under heavy write contention we observed requests hitting the 30-second Lambda timeout. For read-heavy workloads with moderate writes, this is irrelevant. For write-intensive workloads, it's a deal-breaker.

EFS latency also sets a floor. Each durable write requires an fsync round-trip to the file system, which takes 50–100ms on EFS. A local SSD would reduce this to sub-millisecond, but Lambda doesn't offer persistent local storage. This is the price of serverless durability.

What if you need more?

The EFS deployment tops out at ~9 writes per second. For many workloads, that's plenty. But what if it isn't?

We deployed the same API—same schemas, same clients, same federation resolvers—with Confluent Cloud as the storage backend. No code changed. We swapped one configuration.

No schemas changed. No clients changed. No federation resolvers changed. The API contract is identical. The only difference is where the data lives.

The point

The point isn't that every API should run on Lambda, or Kafka, or Kubernetes. It's that meshql makes the infrastructure a detail you choose later.

Start on your laptop with SQLite or an embedded event log. Deploy to Lambda when you need a URL. Move to Confluent Cloud when you need throughput. Graduate to a full cluster when you need everything. The API, the schemas, the clients—they never change.

That's the product.