Systems

Six architectural patterns Emre has put into production, what each one is for, and the engagement where it was applied.

The role Emre states on his CV is a claim about judgement rather than about tools, so this page is written to be checked rather than believed: six patterns he has put into production, what each one actually buys, and a link to the engagement where it was used. The drawings are the argument; the links are the evidence.

Every heading below names a decision with a cost attached. None of them is a preference about style, and each is answerable — a reader who disagrees can open the engagement and see what was built.

Functional core, imperative shell

Functional core, imperative shell An outer rounded band labelled Imperative Shell holds four side-effecting adapters: HTTP and Clock on the left, Database and Queue on the right. Lines carry facts inward from the left adapters into an inner region labelled Functional Core, which holds three pure steps — validate, decide and plan effects — and one line carries the resulting decision back out to the shell, which is what actually performs the effects. A severed line rising from the core is captioned no calls out, showing that the core never depends on the shell. IMPERATIVE SHELL FUNCTIONAL CORE VALIDATE DECIDE PLAN EFFECTS HTTP CLOCK DATABASE QUEUE FACTS IN DECISION NO CALLS OUT The core is pure — every side effect happens out in the shell.

Decision logic is pure and side effects sit at the edges. The core computes what should happen and can be tested without a database, a network or a clock; the shell is the only place anything actually happens.

This is not a preference about style. It is what makes a system's behaviour reproducible: the same inputs give the same decision every time, and the parts that can fail are pushed to a boundary where failure is expected and handled.

APPLIED AT Adopted as the standard across Efsora client projects, and the architecture of AllSober's clinic EMR domain model

A bounded agent loop, and a human at the gate

Bounded agent loop with a human gate A three-node cycle of PLAN, ACT and OBSERVE sits inside a shaded bounded region, and the return edge from OBSERVE back to PLAN runs through a counter of three attempt tokens captioned RETRY CEILING. The outward call from ACT to external tools passes through an open circuit breaker. The only exit from the loop leads from OBSERVE into a prominent HUMAN GATE with two outward edges: APPROVE continues down to COMMIT, REFUSE returns to PLAN, so no path reaches COMMIT without passing the gate. PLAN ACT OBSERVE 1 2 3 RETRY CEILING CIRCUIT BREAKER EXTERNAL TOOLS HUMAN GATE APPROVE COMMIT REFUSE

An agent that plans, acts and observes will loop. The question an architect has to answer is what stops it — so the loop is bounded by a retry ceiling, each outward call sits behind a circuit breaker, and runs that die mid-flight are recovered rather than left orphaned.

Nothing commits without passing a human gate. The gate is not a notification; it is a state the run stops in and stays in until a person approves or refuses.

APPLIED AT Agent Studio at RecVue — LangGraph orchestration behind an Event Shell harness

An outbox, so the agent edge reads committed facts

Transactional outbox to a Kafka agent edge A service writes a business row and an outbox row into one Postgres database inside a single dashed transaction boundary, so both rows commit together or neither does. A relay reads the committed outbox rows and appends them to a partitioned Kafka topic drawn as a row of cells, from which an agent consumer reads. A direct service-to-Kafka path is drawn across the top and severed with a cross, marking the dual write that this pattern removes. SERVICE ONE TRANSACTION ORDERS OUTBOX RELAY PUBLISH KAFKA TOPIC CONSUME AGENT NO DUAL WRITE Both rows commit, or neither. The agent layer reads a committed event, never a table mid-write.

The business row and the event that announces it are written in one transaction. A relay then publishes what has committed, and the agent layer consumes from the topic.

The failure this prevents is subtle and expensive: an agent reacting to a row that was written and then rolled back, or reacting to a table mid-write. Reading from the log means the agent only ever sees what actually happened.

APPLIED AT The ground-up Effect-TS rewrite at RecVue, replatformed off a legacy Oracle system

Tenancy enforced by the database, not by the caller

One table, one connection, isolation at the row Three tenant clients send requests into one shared API, which holds a single connection to one PostgreSQL database. Inside that database a single incidents table holds rows tagged with tenant one, two and three, and a row-level security policy stands as a barrier across the table. The connection carrying tenant two passes the barrier and reaches only its own row, while the reads reaching for the other tenants' rows are severed at the policy. TENANT 1 TENANT 2 TENANT 3 AXUM API no tenant filter in code ONE CONNECTION POSTGRESQL INCIDENTS (ONE TABLE) 1 2 3 RLS POLICY cross-tenant read refused

One table, one connection, and a row-level policy the database applies to every query. Application code cannot forget to add the tenant filter, because the filter is not in application code.

The alternative — a WHERE clause every developer must remember — is one missed clause away from a cross-tenant read, and in an occupational health and safety system that is somebody's medical record.

APPLIED AT Medivizi — a multi-tenant OHS backend in Rust with PostgreSQL Row-Level Security

Caught, capped, and explainable

Guardrails around a model call A request reaches a budget check before the model call; when the budget is exceeded the path branches upward and is severed, so the call never happens. The model output then enters an evaluation stage where two parallel judges, one heuristic and one LLM-as-judge, produce verdicts that combine into a single verdict. A telemetry spine runs beneath the whole pipeline and every stage emits into it. BUDGET CHECK 1 OVER BUDGET capped MODEL CALL 2 HEURISTIC LLM-AS-JUDGE VERDICT caught 3 TELEMETRY explainable

A model call is checked before it runs and judged after. A budget check can refuse the call outright; the response is scored by a heuristic and by a model acting as judge; and every stage emits into one telemetry spine.

That gives three different guarantees, and it is worth naming which is which. The breaker is what catches a failure, the budget is what caps it, and the trace is what makes it explainable afterwards.

APPLIED AT The evaluation framework and cost guardrails at RecVue, with OpenTelemetry throughout

An offline queue that preserves order

Offline queue with ordered replay A client writes actions into an offline queue that holds three numbered items while its link to the server is severed, drawn as a broken line crossed out and captioned LINK DOWN. A lower lane shows the same three items, still numbered one, two and three, draining out of the queue after the connection returns and travelling along a single arrow up into the same server. The lane is captioned as a replay that is oldest first, so the order the client produced is the order the server receives. CLIENT OFFLINE QUEUE 1 2 3 SERVER LINK DOWN 1 2 3 REPLAY, OLDEST FIRST After reconnect the queue drains oldest first, so nothing is lost or reordered.

The interesting constraint is the network that is not there. A client loses signal mid-action, keeps acting, and everything it did has to arrive in the order it was done once the connection returns.

So the client talks to a queue rather than to the API, and the queue is what replays. Order is the whole contract: a move applied out of sequence is a different game.

APPLIED AT ChessDuello — real-time match sync over WebSocket behind an offline queue