Skip to content

career stream woksin · position 18

Sindre Wilting — Co-founder & Chief Architect, Cratis I build systems that remember everything.

Software engineer from Oslo. I work where architecture meets developer experience: event sourcing, event modeling, actor systems and the tools that make them pleasant to use. Co-founder and chief architect of Cratis, an open-source event sourcing platform, and a senior consultant at Everdeen.

View CV GitHub Contact
Command
intent to change
Event
a fact that happened
Read model
a projection of facts

01 Read model

Where the stream is now.

Portrait of Sindre Wilting
Sindre Alstad Wilting Oslo, Norway

Projection: Sindre.Now

projected from 18 events

role
Senior Consultant
company
Everdeen
since
Jun 2025
assignment
Technical lead for the Insights project at Azets, on top of the Azets Common Platform
cratis
Co-founder & Chief Architect at Cratis, since Jun 2024
building
  • Screenplay
  • Stage
  • Cratis AI corpus
  • workstats

About

I am drawn to the lower layers: the frameworks, runtimes and tools that let other developers ship better software faster. The hard part of software is not version 1. It is keeping a system adaptable, understandable and correct for years after.

I think of information systems as flows of information and state. That is why I care about Event Modeling, Event Sourcing and Continuous Delivery: they make the flow explicit, give teams a shared language with the business, and let systems evolve gracefully.

Colleagues describe me as structured, engaged and eager to learn, someone who explains complex things so others can take ownership. Lately I spend a lot of time on agentic engineering: building the guardrails, workflows and tools that make AI coding agents reliable collaborators.

Interests

  • Event Modeling
  • Event Sourcing
  • CQRS
  • Domain-Driven Design
  • Actor systems
  • Distributed systems
  • Developer experience
  • Continuous Delivery
  • Agentic engineering
contributions on GitHub in the last year
32,500 +
merged PRs in the Cratis org as of 16 Oct 2026
3,100 +
committer on 8 Cratis repositories
#1
languages with a Chronicle client
6

02 Event stream

Career, replayed from the event log.

Every role, skill and organisation below is a projection, computed by folding these 18 events in order. Scroll, scrub or press play to watch the state rebuild itself.

Projection: Sindre.Career

position 18 / 18

Last applied

#18 ToolReleased Oct 2026

Current role

Senior Consultant

Everdeen · since Jun 2025

also Co-founder & Chief Architect · Cratis

8.7

years in the field

9

organisations

51

skills

Organisations

  • University of Oslo
  • Norwegian Red Cross
  • Nordkinn Asset Management
  • Dolittle (now Aigonix)
  • DNV · Veracity
  • Stacc
  • Kongsberg Digital · Maritime Simulation
  • Cratis
  • Everdeen

Skill cloud

  • Functional programming
  • Operating systems
  • Information security
  • C#
  • MongoDB
  • Event Sourcing
  • CQRS
  • DDD
  • Event Storming
  • TypeScript
  • .NET
  • SQL
  • Entity Framework
  • Angular
  • DevOps
  • Docker
  • CI/CD
  • gRPC
  • Actor systems
  • Kubernetes
  • Azure
  • GitHub Actions
  • Go
  • Multi-tenancy
  • API design
  • Event-driven architecture
  • Microservices
  • Scrum
  • React
  • SaaS
  • Fintech
  • Orleans
  • Event Modeling
  • OAuth 2.0 / OIDC
  • YARP
  • Architecture
  • Chronicle
  • Arc
  • OpenTelemetry
  • Performance profiling
  • AWS
  • Serverless
  • PostgreSQL
  • Marten
  • GitLab
  • Google BigQuery
  • Data platforms
  • AI
  • Rust
  • ratatui
  • Agentic engineering
  1. Bachelor, IT and Information Systems

    University of Oslo · Oslo

    Picked the fun subjects: computer architecture, information security, operating systems (we built one from scratch), biologically inspired computing and functional programming.

    • + Functional programming
    • + Operating systems
    • + Information security
  2. –

    Digital volunteer, software core team

    Norwegian Red Cross · Oslo

    Community-Based Surveillance: an open-source, event-sourced system for early warning of disease outbreaks. Went from codeathons to the core tech team, led a major database refactoring and ran event storming sessions.

    • + C#
    • + MongoDB
    • + Event Sourcing
    • + CQRS
    • + DDD
    • + Event Storming
    • + TypeScript
  3. –

    IT Analyst (part-time)

    Nordkinn Asset Management

    Full-stack .NET, SQL and Angular. Refactored toward SOLID, introduced Swagger docs and dependency injection.

    • + .NET
    • + SQL
    • + Entity Framework
    • + Angular
  4. –

    Software Development Consultant

    Norwegian Red Cross

    Full-time contract on Community-Based Surveillance. Pushed a DevOps-first culture with automated build, test and deploy pipelines and Docker.

    • + DevOps
    • + Docker
    • + CI/CD
  5. Graduated, University of Oslo

    University of Oslo

    Bachelor degree completed.

  6. OSS Platform Engineer

    Dolittle (now Aigonix) · Oslo

    Joined a startup almost from day one. Designed and built a multi-tenant event sourcing runtime on .NET, an actor framework, MongoDB and gRPC. Ran SLA-bound hosting on Azure Kubernetes and automated delivery with GitHub Actions.

    • + .NET
    • + gRPC
    • + Actor systems
    • + Kubernetes
    • + Azure
    • + GitHub Actions
    • + Go
    • + Multi-tenancy
    • + API design
  7. Software Engineer

    DNV · Veracity · Høvik

    Event-driven microservices data platform in a large international team. Standardised tooling and built reusable .NET libraries used across the software division.

    • + Event-driven architecture
    • + Microservices
    • + Scrum
  8. Three Microsoft Azure certificates

    Coursera

    Azure Services and Lifecycles; Azure Management Tools and Security Solutions; Introduction to Microsoft Azure Cloud Services.

  9. Senior Systems Developer

    Stacc · Oslo

    Fintech for banks across Oslo and Serbia. Revived a legacy application, set up CI/CD with coverage and vulnerability tracking, and started the move toward multi-tenant SaaS and event-driven design.

    • + React
    • + TypeScript
    • + SaaS
    • + Fintech
  10. Tech Lead, OCEAN

    Kongsberg Digital · Maritime Simulation · Horten

    Headhunted to lead OCEAN: a greenfield, event-sourced microservice system adding role-based access control to maritime simulators, on-prem or in the cloud. Ran event modeling sessions, coached the team, and owned the gateway and identity design.

    • + Orleans
    • + Event Modeling
    • + OAuth 2.0 / OIDC
    • + YARP
    • + Docker
    • + Architecture
  11. Co-founder & Chief Architect

    Cratis

    Co-founded Cratis with Einar Ingebrigtsen: an open-source event sourcing platform, from the Screenplay modeling language to the Chronicle event store. Architect, developer and content creator. OCEAN was built on it, so the framework and the product improved together.

    • + Chronicle
    • + Arc
    • + OpenTelemetry
    • + Performance profiling
  12. OCEAN live at a customer site in England

    Kongsberg Digital · Maritime Simulation

    Led the technical rollout on site, debugged first-deployment issues and made sure it worked in a real operating environment.

  13. Senior Consultant

    Everdeen · Oslo

    Everdeen is an approved Norwegian staffing firm for senior independent consultants, with assignments through Hive Consulting. Assigned to the Azets Common Platform: a serverless, multi-tenant, event-driven integration platform syncing accounting and payroll data for thousands of Nordic customers. Owned data flow between integration sources and ran event modeling sessions.

    • + AWS
    • + Serverless
    • + PostgreSQL
    • + Marten
    • + GitLab
  14. Technical lead, Insights project

    Azets (via Everdeen)

    Leading the technical work from discovery interviews with advisers and management to a BigQuery-based data foundation for analytics and AI.

    • + Google BigQuery
    • + Data platforms
    • + AI
  15. Webinar: Event Modeling

    Hive Consulting

    With Einar Ingebrigtsen (Novanet): how Event Modeling and Event Sourcing create clarity, shared understanding and control in complex projects.

  16. Webinar: Event Sourcing

    Novanet × Hive Consulting

    With Einar Ingebrigtsen: what event sourcing is, CQRS, projections and event stores, and lessons from real production implementations with Cratis.

  17. reap v5

    woksin

    Rust TUI that finds stale developer junk and prunes only what is provably safe to lose.

    • + Rust
    • + ratatui
  18. workstats v1.11

    woksin

    Local-first analytics of Git and AI-assisted work. Zero telemetry.

    • + Rust
    • + Agentic engineering

03 How I think

Start with the event model.

Before code, I draw how information flows: screens send commands, commands append events, events feed read models, read models feed screens. This is a real slice from Varde, my family app, and every name on it is a type in its source.

EventModel: Varde · Chores

Screens
Commands · Read models
Chore stream
Member stream

Hover, focus or tap a card, or play the flow.

4 steps, 12 cards, two streams: chores are keyed by chore, completions by member.

04 Co-founder · Chief Architect

What I lead at Cratis.

Cratis makes event sourcing and CQRS practical: a production-grade event store and runtime, an opinionated application framework, and tooling that lets teams without event sourcing experience build robust, multi-tenant systems.

Cratis is a company of two: Einar Ingebrigtsen and me. I lead the stack from model to running app: the Screenplay language, the Stage renderer, the AI corpus, the cli and most Chronicle clients.

committer on 8 Cratis repositories
#1
repositories founded: AI, cli, Chronicle.Go, Chronicle.Python
4
Chronicle client languages: .NET, TypeScript, Kotlin/Java, Elixir, Go, Python
6
merged PRs in the Cratis org (3,179, as of 16 Oct 2026)
3,100+

05 Event store

Every contribution, appended.

My GitHub contribution calendar, re-projected as an event store: one partition per day, brighter means more events appended. Captured when the site was built.

EventStore: github.com/woksin · partitioned by day

snapshot taken

32,528 events appended in the last year

activeDays
243 / 370
longestStreak
62 days
currentStreak
34 days
busiestDay
1,559 · Thu, 24 Sept 2026
Contributions per month
MonthContributions
October 202531
November 202552
December 202526
January 202643
February 2026160
March 2026311
April 202690
May 2026357
June 2026599
July 20261,806
August 20266,826
September 202610,314
October 202611,913

06 Agentic engineering

I build the harness.

Using coding agents is the easy part. I build what makes them reliable collaborators: the rules, routing, guards, queues and reviews around them, and the tools that measure what they actually do.

Workflow: every change in my setup

32,528 contributions · 17,968 commits in the last year

  1. 01 · Orchestrator Plan TaskPlanned Scopes the change and writes a brief with owned files, the exact gate command and a done condition.
  2. 02 · Pinned subagent Implement ChangeImplemented A subagent type pinned to a model and thinking level does the work inside the brief.
  3. 03 · Other provider Review ChangeReviewed Adversarial review by a model from another provider. Only confirmed blocking findings send it back. ↺ blocker → Implement
  4. 04 · Local CI mirror Gate GatesPassed The same build, lint and tests as CI, run locally through a priority build queue before anything is pushed.
  5. 05 · Orchestrator Ship PullRequestMerged Push once, wait for CI without polling, merge, and close the issue.

07 Side projects

Things I build after hours.

  • CLI

    workstats v1.11.0

    See where the work happened, without sending your work anywhere.

    • Separates human, agent-authored and AI co-authored commits
    • Agent wall-clock, parallelism and token usage
    • Open JSONL event format
    • Zero telemetry
    brew install woksin/workstats/workstats
    • Rust
  • CLI

    reap v5.0.4

    Find and prune stale developer junk, and know which of it you can afford to lose.

    • Branches, worktrees, build artifacts, Docker and caches
    • Safe / rebuildable / irreversible tiers
    • Only prunes what is provably safe
    • Built for the age of agentic programming
    brew install woksin/reap/reap
    • Rust
    • ratatui
  • CLI

    gearprice v0.2.2

    What guitar gear costs on Reverb right now, and what class it sits in.

    • Price bands from steal to premium
    • Category percentile across 100k+ listings
    • Reads full live listing sets
    brew tap woksin/gearprice && brew install gearprice
    • Rust
  • A self-hosted family life operating system on a kitchen wall tablet.

    • Chores, rewards, routines, meals, lists and calendar
    • No punishments, no leaderboards
    • One Docker Compose stack on the LAN
    • Built on Cratis Arc and Chronicle
    • .NET 10
    • Chronicle
    • Arc
    • React 19
    • Tailwind
  • Agent tooling

    pi-setup

    My whole AI coding agent setup: rules, agents, guards, review workflows and model routing.

    • Pinned-model subagents
    • Cross-provider review workflow
    • Guards, issue tracking, phase queue
    • Usage and cleanup tooling
    • TypeScript
    • Python
    • Bash
  • Agent tooling

    pi-jobs

    Background jobs and watches that wake the agent when they finish, at zero token cost.

    • job_start / job_watch
    • Process-group supervision
    • No polling
    pi install npm:@woksin/pi-jobs
    • TypeScript
  • Agent tooling

    pi-recover

    Pick up subagents, jobs and workflows from a session that stopped abruptly.

    • Deterministic session parsing
    • Recovery report with original prompts
    • Dry-run mode
    pi install npm:@woksin/pi-recover
    • TypeScript

08 PostPublished

Appended to the blog.

38 posts on blog.cratis.io, about 9 hours of reading, most of them the Decisions that hold series: from naming an event to running it in production.

  1. Part 11 Questions and a decision guide Ten posts on keeping a decision true at the moment it is written, and one page that tells you which mechanism a rule needs, what fails without an error, and where each answer is explained in full. arcchronicleconcurrencyconstraintsevent-sourcing · 17 min read
  2. Part 10 How a guard is built, merged and widened A guard is a position in the log and a filter. This part takes one apart: where the position and the filter come from, what a second read does to them, how an explicit scope and declared concurrency join in, and how to print what a commit actually guarded. arcchronicleconcurrencyevent-sourcing · 12 min read
  3. Part 09 Testing a decision against a race A test that runs one command at a time passes with a plain read too. One line in an Arc command scenario puts a competing write between the read and the commit, and turns 'it works' into 'it still holds when someone else is faster'. arcchronicleconcurrencyevent-sourcingvalidation · 9 min read
  4. Part 08 The same guard without Arc: decision reads and append conditions Under Arc's read protection is one Chronicle call you can make yourself: note where the log was, fold the state, and append only if nothing it depended on arrived since. This part writes that guard by hand, and says exactly what it is in DCB terms and what it is not. chronicleconcurrencyevent-sourcing · 13 min read
  5. Part 07 Not every rule needs a guarded read Read protection is the answer for state on a key you read. It is the wrong answer for a unique email, a document two people edit, or a rule you would rather repair later. Pick by the shape of the rule, and know which choices fail silently. arcchronicleconcurrencyconstraintsevent-sourcing · 16 min read
  6. Part 06 Turning read protection on in an application that already runs You can't switch a running application to 'refuse unguarded reads' on a hunch. Measure runs every command as before and reports which reads On would guard, which it would refuse, and which appends it would reject. Here is the path from Off to On, what a real report looks like, and how to back out. arcchronicleconcurrencyevent-sourcing · 14 min read
  7. Part 05 When Arc says no Read protection says no in two ways. A 400 means something the command read changed: read again and decide. A 500 means the code reads something Arc can't guard: change the code. And under Off, a caller can turn a validator's no into a yes. arcchronicleconcurrencyvalidationtypescript · 13 min read
  8. Part 04 A limit for one account and one month A monthly withdrawal limit depends on one month of one account. Declare that stream on the read model and route the command to it, and the guard covers that month only: a withdrawal in October conflicts, one in November doesn't. arcchronicleconcurrencyevent-sourcingvalidation · 9 min read
  9. Part 03 One rule, two entities, one append A member may hold three loans, and a book has one copy left. Two read models in one validator, one fact for each entity, one atomic append, and if either side changed after the read, nothing is written. arcchronicleconcurrencyevent-sourcingvalidation · 9 min read
  10. Part 02 The read model said yes A command that reads a read model and then appends can approve the same last copy twice. One project setting turns that read into a guard: the same command, the same validator, and the loser of the race gets a 400 that says nothing was written. arcchronicleconcurrencyevent-sourcingvalidation · 11 min read
  11. Part 01 The bug you never see Is there stock? Is the name free? Is the balance enough? Every check-then-act decision has a gap between the check and the write, and two requests can both pass it. Nothing throws, the tests are green, and the bad state turns up weeks later. Why that is, what the database defaults do and don't do, and how to spot it in your own code. concurrencyevent-sourcingcqrspostgresqlsql-server · 14 min read
  12. Part 01 Events are facts: naming and shaping events An event records something that happened, and no event is taken out of the log afterwards. How to name and shape events that still read in five years, and what Chronicle stores with each one: a sequence number, its source, the operation it belonged to, who caused it and why. chronicleevent-sourcingevent-modelingarc · 14 min read
  13. Part 02 Inside Chronicle: how the event store appends events Chronicle's append returns without waiting for a single projection. What the kernel does inside that call, how observers and partitions pick the event up afterwards, and what happens when one of them fails. chronicleevent-sourcingorleansarchitecture · 12 min read
  14. Part 03 Projections and read models in Chronicle and Arc One attribute turns AuthorRegistered into a list on a screen. Model-bound, fluent and PDL projections, reducers for when attributes can't say it, where read models are stored, how a live list learns about changes, and what Chronicle does when a projection changes or has to be rebuilt. chroniclearcprojectionsread-modelsevent-sourcing · 13 min read
  15. Part 04 Reactors, webhooks and subscriptions: reacting to events Reactors, webhooks and outbox-to-inbox subscriptions carry what happened to whoever cares. A failing handler stops one partition, a reactor can return its follow-up facts, and a stable delivery id is what lets a side effect survive running twice. chroniclereactorswebhookssubscriptionsevent-sourcing · 13 min read
  16. Part 05 Event sourcing constraints and concurrency at write time Checking a plain read model before you append enforces nothing. Constraints, concurrency scopes, decision reads, Arc's read protection and Arc aggregates check at write time, and each reaches a different set of appends. chroniclearcconstraintsconcurrencyevent-sourcing · 16 min read
  17. Part 06 CQRS with Arc: commands and queries without the plumbing A command is a record with a Handle method and a query is a static method on the read model it returns. What Arc builds from those two shapes, in which order it checks a request, what reaches the generated TypeScript, and what stays the application's job. arccqrsdotnettypescriptvalidation · 14 min read
  18. Part 07 Validation in a CQRS app, from browser to event log Every place a rule can live in a Cratis application, from the rules copied into the browser to Chronicle's append. What each layer can and can't guarantee, why a taken author name is caught in only one of them, and which rejections find their way back to a form field. validationarcchronicleconstraintstypescript · 14 min read
  19. Part 08 Live queries and real-time React UIs with Arc In Arc, a query that loads once and a query that keeps pushing results to React differ by one return type, given data that notifies on change. The whole path from a write to the screen, the transport underneath, the hook and its states, command dialogs, view models and live tables, and which hop is live and which is a snapshot. arccomponentsreactobservable-queriestypescript · 16 min read
  20. Part 09 Cratis Components: the React layer for Arc The author list and the register dialog from the cratis template, built with Cratis Components 4. Which parts come from Components and which from Arc, how a field binds to a generated command, how a taken name gets back to the Name field, theming and renderer adapters, and where the library stops. componentsreactarctypescriptfrontend · 14 min read
  21. Part 10 Multi-tenancy and identity with AuthProxy, Arc and Chronicle AuthProxy signs the user in, picks a tenant and forwards it as x-cratis-tenant-id, the header Arc reads by default, and Chronicle turns the tenant into a namespace. Every hop from the edge to storage, what a missing tenant becomes at each one, and what stays yours to check. tenancyidentityauthproxyarcchronicle · 16 min read
  22. Part 11 Testing event-sourced apps with Arc and Chronicle Most specs in a Cratis application can call a method and compare the event it returns. What the in-process scenarios add on top, the ways a green spec proves nothing, and the few tests that still need a real Chronicle and a running host. testingarcchroniclespecificationsevent-sourcing · 13 min read
  23. Part 12 Event sourcing beyond .NET: Kotlin, Java, TypeScript, Elixir Chronicle has clients for .NET, Kotlin and Java, TypeScript and Elixir, and Arc has servers on ASP.NET Core, Spring Boot and, as a source preview, Node.js. What each one gives you today, which registry it comes from, and the defaults that still differ from .NET. arcchroniclekotlintypescriptelixir · 16 min read
  24. Part 13 Personal data in an event log: PII and crypto-shredding Chronicle erases a person by destroying their key. The events stay, their marked values read as empty, and the fence stops the key from coming back. chroniclearcpiiprivacyevent-sourcing · 16 min read
  25. Part 14 Event sourcing in year two: changes, replays and corrections A new event shape, a new view over old events, a correction to a stored fact and an observer stuck on one stream look alike, and they aren't. What each one changes in Chronicle, what the kernel works out on its own, and what an operator still decides. chronicleevent-sourcingmigrationsreplayoperations · 13 min read
  26. Part 15 Arc gotchas: validation, proxy generation and naming conventions Three places Arc's conventions make a decision you might not see: a validator that runs in the browser and on the server but not identically, a proxy folder the generator owns, and routes, event identities and mappings chosen by a name. What each one does, and the fix. arcproxy-generationvalidationchronicletypescript · 13 min read
  27. Part 16 Chronicle Workbench: a browser UI for your event store The Chronicle server serves its own browser tool on the port your clients already use. What each screen shows, how to follow a failed partition back to one author, and which screens can change a store. chronicleworkbenchoperationsevent-sourcing · 11 min read
  28. Part 17 The Cratis CLI: diagnose, workbench and llm-context A diagnostic summary that fails on a failed partition and not on lag, a full-screen terminal workbench for the box you reached over SSH, and a command catalog that tells an agent which commands change the server. clichronicleoperationsaievent-sourcing · 13 min read
  29. Part 18 Running Chronicle in production: storage, security, backup What Chronicle's production image won't start without, how the storage choice changes where read models land, what a client trusts until you tell it otherwise, where a trace stops today, and the backup order that decides whether a restore can be read. chronicleoperationshostingsecurityobservability · 15 min read
  30. Part 19 Chronicle replay jobs, scale and performance Replays you can stop and resume, what a crash in the middle of one delivers twice, how events reach observers without making appends wait, and what running Chronicle on more than one node does and doesn't promise. chronicleoperationsperformanceclusteringevent-sourcing · 13 min read
  31. Part 20 Event modeling with Screenplay: a model you can compile The .play language for writing an event model down next to the code, a compiler whose diagnostic codes don't change, personal data declared once on a value, and an MCP server that lets an assistant propose changes a person applies. screenplayevent-modelingclimcpai · 13 min read
  32. Part 21 Stage and Scene: generating code from an event model Stage renders a narrow slice of a Screenplay model into C# on Arc and Chronicle, boots a throwaway sandbox and runs the model's examples, and refuses with a code whatever it can't express. Scene is the UI model between a screen in the model and React. stagescenescreenplayevent-modelingarc · 12 min read
  33. Part 22 Prologue: a first event model of an existing system Prologue stands beside a running system, records the metadata of what it does, and proposes a Screenplay model for a person to correct. What it watches, what it never records, how it groups what it sees, and what a language model may and may not change. prologuescreenplayevent-modelingcliai · 12 min read
  34. Part 23 Cratis Studio: event modeling for the whole team A shared board and canvas where people and AI agents work on the same event model, Screenplay text you can diff, and opt-in code for one slice in your own repository. What Cratis Studio does at each step, and where each step stops. cratis-studioevent-modelingscreenplaystageai · 11 min read
  35. Part 24 Cratis Direct: an agentic development life cycle How a person admits agent work in Cratis Direct, what each gate records, and who merges the pull request. The control plane we run our own engineering on, followed through one issue, and where it stops. cratis-directagentsaiengineeringchronicle · 11 min read
  36. Part 25 AI across the Cratis stack: corpus, CLI and MCP Where an assistant meets Cratis: the AI corpus and its hooks, the CLI's effect labels, Chronicle MCP, Screenplay MCP and the docs assistant. What each one lets an assistant read, propose or change, and the checks that run whether it listened or not. aimcpclichroniclescreenplay · 14 min read
  37. Part 26 Getting started with Cratis: templates, samples and tools From an empty folder to a running Cratis application with dotnet new cratis or cratis new, the samples and what each leaves out, and the smaller tools around the stack: Fundamentals, Specifications, Synopsis, Narrator, Lens and the docs. It closes with where to start and the full series index. templatessamplesfundamentalsspecificationssynopsis · 21 min read
  38. Overview Event sourcing with Cratis: one feature from model to production The sticky-note feature followed from its model to production, into year two and to agents writing its code, through every Cratis product this post names, with 26 more posts that take each one all the way down. ecosystemauthproxyarcchroniclecli · 26 min read

snapshot taken

10 Read model

The toolbox.

Architecture & methods

  • Event Modeling
  • Event Sourcing
  • CQRS
  • DDD
  • Event Storming
  • Microservices
  • Actor systems
  • Multi-tenancy
  • TDD / BDD
  • Continuous Delivery

Languages

  • C#
  • TypeScript
  • Rust
  • Go
  • SQL

Platforms & frameworks

  • .NET / ASP.NET Core
  • Orleans
  • Cratis Chronicle & Arc
  • Marten
  • React
  • gRPC
  • OpenTelemetry

Data

  • MongoDB
  • PostgreSQL
  • SQL Server
  • Google BigQuery

Cloud & ops

  • Azure
  • AWS
  • Kubernetes
  • Docker
  • GitHub Actions
  • Prometheus
  • Grafana

Agentic engineering

  • Multi-agent workflows
  • Cross-provider review
  • Agent guardrails
  • Claude, GPT and open models

07Command

Append an event to my stream.

Questions about event sourcing, Cratis, a project or a role? Issue the command and it lands in my inbox.

Command woksin/inbox

SendMessage

to
sindrewilting@gmail.com
from
you
channel
email · LinkedIn · GitHub

Event pending

MessageRequested

Write an email
↑↓ navigate ↵ run

woksin@stream: ~

Type help for a list of commands. Up and down browse history, Tab completes, Escape closes.