DE
Contact
Menu
DE

Timothy Fehr · Zürich

Software architecture and backend development

I'm a software architect and backend developer in Zürich and take on independent work, remotely and on site.

I take on architecture questions, technical reviews, and defined backend or integration changes. Depending on the assignment, you get a written recommendation or a tested change handed over to your team.

My focus is Java and Spring Boot, along with integrations, permissions and automating builds and deployments. At finnova I developed central backend components for interbank messaging and was responsible for the build and release automation of a Keycloak-based authorisation layer.

timothy.fehr@fehrcoding.ch How I can help

Who can access which building's data?

MonitoringHive

My own project · In development

A building-monitoring platform I designed and built. Each party may see only its own buildings, and afterwards it has to be clear why a request was allowed or refused.

How MonitoringHive checks access

Java 21, Spring Boot, PostgreSQL, Keycloakmonitoringhive.ch

How MonitoringHive decides access, simplified A request to a guarded endpoint goes to one policy evaluator, which denies by default and returns allow or deny with a reason. Each evaluation writes one row to a decision log in a separate transaction. Independently, PostgreSQL row-level security limits the tenant-scoped tables to the current tenant. Request Policy evaluator deny by default allow / deny + reason Decision log one row per evaluation PostgreSQL row-level security tenant tables 1 2 3
  1. Guarded service endpoints ask one evaluator. It denies by default and names the reason; a build test fails if an endpoint is neither guarded nor allowlisted.
  2. Each evaluation writes one decision-log row in a separate transaction, so the record survives when the operation itself is rolled back.
  3. PostgreSQL row-level security limits the tenant-scoped tables to the current tenant, even when a query omits the tenant filter.

Blue: the decision · dashed: evidence

Facing a similar question in your own system? Write to me

All projects

From the notes ·

Chain the builds, or split and bind?

Build pipelines for a Keycloak with several custom plugins.

Why a retry can create two invoices

A timeout doesn't tell you whether the invoice was created.

Billing requests an invoice for an order and stops waiting after 5 seconds. Compare two scenarios: the provider answers late, or the first request never reaches it.

Try the comparison

Sequence diagram: a retry creates a second invoice Billing asks the invoice provider to create an invoice for order 1042. The provider creates INV-1 but answers slowly. After 5 seconds billing stops waiting and sends the same request again. The provider treats it as new and creates INV-2, then answers with INV-2. The late answer with INV-1 arrives after 45 seconds. Result: two invoices for one order. Billing Invoice provider create invoice, order 1042 creates INV-1 timeout 5 s retry: create invoice, order 1042 creates INV-2 INV-2 INV-1 (after 45 s) 2 invoices for 1 order

Contact

timothy.fehr@fehrcoding.ch

Briefly describe the problem or decision you need help with. What to include