Head of Engineering, Backend engineer and software architect at ZITADEL, building open-source identity infrastructure in Go and PostgreSQL. My work centres on database-backed performance, authorization architecture and security primitives.

A Go library that puts many password hashing algorithms behind one API. It lets an identity provider change algorithms or cost parameters without forcing users to reset their passwords.

• Created it in September 2022 and am its main author: 36 of 47 human-authored commits.
• One Swapper API: new hashes use the configured algorithm, while Verify still accepts legacy hashes and transparently returns an upgraded hash when the algorithm or parameters are outdated.
• Supports argon2i/id, bcrypt, scrypt, pbkdf2 and sha2-crypt, plus verify-only legacy formats (md5-crypt, salted MD5, phpass for WordPress/phpBB, Drupal 7) for migrating users from other systems.
• Uses the Modular Crypt Format, tested against reference hashes from Python's Passlib. The only dependencies are the Go standard library and golang.org/x.
• Used in production by ZITADEL for user passwords and, since zitadel#7657, for machine and app secrets.

Over 35 performance pull requests on ZITADEL's event-sourced core, running from 2023 to today. Measured with ZITADEL's own published k6 benchmarks:

In the latest runs the database CPU is the limit (96–98%) while ZITADEL itself uses under 40% CPU, so the application is no longer the bottleneck.

Each approach collapses many database round trips into a single query and takes projection updates off the request path.

Other current benchmarks (#12651, 600 VUs, 30 minutes): PAT login 3,452 req/s, client credentials 834 req/s.

• #12753: made projection catch-up reads efficient under a large backlog. The batch query went from 832 ms to 4 ms (~200×) and drain throughput from 975 to 7,811 events/s (~8×) with 4.8M events of backlog.
• #8940, #8788, #8747, #10564: index-only event filtering, removal of costly always-running reducers, and direct queueing for Actions v2 instead of an all-instance projection.
• #12449: autovacuum tuning for the ever-growing events table.

• #8628: generic cache interface with in-memory and no-op backends.
• #8703: PostgreSQL connector on unlogged tables, partitioned by cache.
• #8822, #8890, #10658: Redis connector with atomic Lua scripts, a circuit breaker, and non-blocking UNLINK deletion.
• #8903: instance and organization caching on every request.

• #9152, #9677: role permission checks moved into PL/pgSQL over a denormalized fields table, replacing per-row checks in application code.

As an architect on ZITADEL's next-generation platform I write the epics that set its design direction. Both are in progress.

I designed a portable, relational FGA (fine-grained authorization) core. One model covers ZITADEL's own resources and customers' application permissions. The design is recorded in ADRs 032–034 (#493).

• OpenFGA as the policy language only. ZITADEL does its own validation, compilation and SQL query planning on PostgreSQL and Spanner.
• Authorization data lives next to the resources it protects: no sidecar and no synchronization lag.
• Role implications are resolved once, when a policy is uploaded, not on every write. Adding a user to a group of 100k members writes one row, not 100k.
• List endpoints get the authorization filter injected into their SQL, so there are no O(n) per-row checks.
• A strict 403-vs-404 rule avoids leaking whether a resource exists, and a full audit trail covers delegated and agent actions.
• Split into 9 sub-issues and delivered with the team. The core catalog, compiler, schema and resolver are done.

This epic sets up the platform's first performance program, to measure the architectural bet of relational storage over an eventstore before public launch.

• An exploratory profiling run exposed bottlenecks nobody had diagnosed: an uncached RSA-4096 key unwrap on every request, per-request audit writes, and logging overhead costing ~23% of throughput.
• Designed a k6 load harness that runs the same deployment against SQLite, PostgreSQL and Spanner, so a throughput ceiling can be attributed to the database or to the application. It adds application-level tracing and metrics.
• Scoped into 19 sub-issues across six dependency waves, covering 28 API operations in the first wave. The first finding already turned into a key-chain cache (854 µs → 30 ns per lookup).

_{Go · PostgreSQL · Cloud Spanner · Redis · OIDC / OAuth 2.0 · Event sourcing · Authorization (FGA / ReBAC) · Performance engineering}