Ten Languages, One Release: Daily life of a polyglot
Shipping Rust, Protobuf, Go, TypeScript, JSON config, SQL migration, Python validation, Dockerfile, Terraform, and Bash.
Shipping real systems almost never stays inside one language boundary. A single feature often spans runtime code, wire formats, migrations, infrastructure, and automation in parallel.
This article is intentionally brief: one tiny end-to-end release, ten snippet types. But mostly, its to test the css styling of code snippets, and I think they look grand.
1) Rust service logic
Our API service computes a deterministic release key from tenant + environment, and rejects unsafe environment names early.
use std::fmt;
#[derive(Debug)]
pub struct ReleaseKey(String);
#[derive(Debug)]
pub enum ReleaseError {
InvalidEnvironment(String),
}
impl fmt::Display for ReleaseError {
fn fmt(&self, f: &mut fmt::Formatter<'_>) -> fmt::Result {
match self {
ReleaseError::InvalidEnvironment(env) => {
write!(f, "invalid environment: {}", env)
}
}
}
}
pub fn build_release_key(tenant: &str, environment: &str) -> Result<ReleaseKey, ReleaseError> {
let allowed = ["dev", "staging", "prod"];
if !allowed.contains(&environment) {
return Err(ReleaseError::InvalidEnvironment(environment.to_string()));
}
Ok(ReleaseKey(format!("{}::{}", tenant.trim().to_lowercase(), environment)))
}2) Protobuf wire format
The release event schema lives in Protobuf. This is the contract between the Rust API, the Go notification service, and any future consumer.
syntax = "proto3";
package releases.v1;
message ReleaseEvent {
string id = 1;
string service = 2;
string environment = 3;
string status = 4;
int64 created_at = 5;
}
service ReleaseNotifier {
rpc Notify (ReleaseEvent) returns (NotifyResponse);
}
message NotifyResponse {
bool accepted = 1;
string message = 2;
}3) Go notification service
The Go service consumes the Protobuf contract above. When the Rust API emits a release event, this service picks it up and fans out notifications.
package main
import (
"context"
"fmt"
"log"
pb "datakey/releases/v1"
)
type notifier struct {
pb.UnimplementedReleaseNotifierServer
}
func (n *notifier) Notify(ctx context.Context, event *pb.ReleaseEvent) (*pb.NotifyResponse, error) {
if event.Environment == "prod" {
log.Printf("PROD release: %s (%s)", event.Id, event.Service)
}
msg := fmt.Sprintf("release %s accepted for %s", event.Id, event.Environment)
return &pb.NotifyResponse{Accepted: true, Message: msg}, nil
}4) TypeScript client request
The web client sends a release request and surfaces server errors without swallowing context.
interface ReleasePayload {
tenant: string;
environment: "dev" | "staging" | "prod";
}
interface ReleaseResponse {
id: string;
status: string;
createdAt: string;
}
export async function createRelease(payload: ReleasePayload): Promise<ReleaseResponse> {
const response = await fetch("/api/releases", {
method: "POST",
headers: { "content-type": "application/json" },
body: JSON.stringify(payload),
});
if (!response.ok) {
const detail = await response.text();
throw new Error(`Release creation failed (${response.status}): ${detail}`);
}
return response.json();
}5) JSON deployment contract
This file is what CI and runtime agree on. Keep it explicit and small.
{
"release": {
"id": "2026-04-28.1",
"service": "datakey-web",
"environment": "staging",
"rollout": {
"strategy": "linear",
"stepPercent": 25,
"pauseSeconds": 300
}
}
}6) SQL migration
The release table tracks auditability and rollback visibility.
CREATE TABLE IF NOT EXISTS releases (
id TEXT PRIMARY KEY,
service_name TEXT NOT NULL,
environment TEXT NOT NULL,
status TEXT NOT NULL CHECK (status IN ('pending', 'active', 'rolled_back')),
created_at TIMESTAMPTZ NOT NULL DEFAULT NOW()
);
CREATE INDEX IF NOT EXISTS idx_releases_service_env
ON releases (service_name, environment, created_at DESC);7) Python smoke validation
Before we mark a release active, we run a fast data sanity check.
from dataclasses import dataclass
@dataclass
class SmokeResult:
ok: bool
message: str
def verify_row_count(expected_min: int, actual: int) -> SmokeResult:
if actual < expected_min:
return SmokeResult(False, f"row count too low: expected >= {expected_min}, got {actual}")
return SmokeResult(True, f"row count check passed ({actual})")
if __name__ == "__main__":
result = verify_row_count(expected_min=1000, actual=1243)
print(result.message)
raise SystemExit(0 if result.ok else 1)8) Dockerfile
The container build is its own language with its own failure modes. Layer order matters for cache hits.
FROM rust:1.78-slim AS builder
WORKDIR /app
COPY Cargo.toml Cargo.lock ./
COPY src/ src/
RUN cargo build --release --bin datakey-web
FROM debian:bookworm-slim
RUN apt-get update && apt-get install -y ca-certificates && rm -rf /var/lib/apt/lists/*
COPY --from=builder /app/target/release/datakey-web /usr/local/bin/
EXPOSE 8080
ENTRYPOINT ["datakey-web"]9) Terraform infrastructure
The staging environment needs to exist before the deploy hits it. Terraform owns that.
resource "google_cloud_run_v2_service" "datakey_web" {
name = "datakey-web"
location = "australia-southeast1"
template {
containers {
image = "gcr.io/datakey-prod/datakey-web:${var.release_id}"
resources {
limits = {
cpu = "1"
memory = "512Mi"
}
}
env {
name = "ENVIRONMENT"
value = var.environment
}
}
scaling {
min_instance_count = 0
max_instance_count = 4
}
}
}10) Bash orchestration
Bash is still the connective tissue in many release workflows.
#!/usr/bin/env bash
set -euo pipefail
ENVIRONMENT="${1:-staging}"
RELEASE_ID="$(date +%Y-%m-%d).1"
echo "Running checks..."
pnpm check
echo "Applying migration..."
psql "$DATABASE_URL" -f migrations/20260428_create_releases.sql
echo "Triggering deploy..."
curl -sS -X POST "https://deploy.internal/releases" \
-H "content-type: application/json" \
-d "{\"id\":\"$RELEASE_ID\",\"environment\":\"$ENVIRONMENT\"}"
echo "Release $RELEASE_ID queued for $ENVIRONMENT"A useful heuristic: if a release depends on more than three languages and one of them is shell, write the checklist down before writing more code.