Clarify the problem
Turn implicit knowledge into shared language, boundaries, and examples.
Staff Software Engineer · Team multiplier
I help engineering teams make hard systems easier to understand, build, and improve.
I work best where the problem is still messy: too much implicit knowledge, unclear ownership, brittle integrations, or a team that needs a path through the noise. I build the system, explain the tradeoffs, and leave behind tools and context other people can reuse.
Role
Staff+ backend engineer
Known for
Complex systems made understandable
How
Code, docs, and tools teams reuse
Yonatan Karp-Rudin
Staff Software Engineer Builder · explainer · team multiplierHow I multiply a team
Build the path
Create the code, contracts, tools, and tradeoffs that make the direction real.
Leave leverage
Document the decisions, reusable pieces, and handoff details so others can keep moving.
Payments / risk / compliance systems
Kotlin/JVM, Spring Boot, Kafka, OpenAPI
OSS, docs, templates, teaching
Multiplier effect
What good teams get from working with me.
A practical way of working: make the problem understandable, build the path, and leave behind reusable context for the next engineer.
Shared understanding
People can talk about the system with the same words, fewer assumptions, and less folklore.
Better decisions
Tradeoffs are written down clearly enough that the team can challenge, revisit, and improve them.
Reusable patterns
Repeated problems become examples, libraries, templates, and habits instead of private knowledge.
Stronger ownership
The system is easier to change because more people understand how and why it works.
Proof
Examples of multiplying a team, not just finishing a ticket.
Shared language
Making messy domains easier for a team to reason about.
- Problem
- When a workflow crosses services, teams, vendors, and product assumptions, the hard part is often not the code. It is agreeing on what the system means.
- Leverage
- I turn that ambiguity into names, boundaries, examples, contracts, diagrams, and enough implementation detail to test the idea against reality.
- Result
- The team gets a shared model it can use in planning, code review, debugging, onboarding, and the next round of changes.
Reusable paths
Turning repeated friction into tools and habits.
- Problem
- If several people are solving the same setup, monitoring, integration, or documentation problem, the organization is paying the cost more than once.
- Leverage
- I look for the small reusable piece: a template, a library, a Backstage tool, a runbook, a checklist, or a better example repository.
- Result
- The next engineer starts from a clearer path instead of rediscovering the same context from memory.
Public explanation
Writing and OSS as part of the engineering work.
- Problem
- Explaining something well is a forcing function. It exposes gaps in the model and makes the useful parts available beyond the immediate conversation.
- Leverage
- I write, teach, contribute upstream, and publish small tools when a lesson is useful enough to be reused.
- Result
- The work helps people outside the original team, and it makes my own thinking sharper for the next hard problem.
When to call
I am useful when the team needs clarity as much as code.
A problem is important, but the team is still arguing from different mental models.
A backend system works, but too much of it depends on hidden context and a few people's memory.
A repeated engineering problem deserves a reusable tool, template, library, or explanation.
A team needs a senior engineer who can clarify the work, build the path, and help others own it.
How I work
I like the moment when a hard thing becomes clear enough for a team to move.
A lot of engineering work is not blocked by a missing framework or one clever abstraction. It is blocked because the team does not yet have the same picture in its head: what the system is for, where the boundaries are, which tradeoffs matter, and what will make the next change easier or harder.
That is where I tend to be useful. I ask questions until the shape appears, build enough of the real thing to prove the direction, and explain the result in a way other people can use. Sometimes that becomes production code. Sometimes it becomes a library, a template, a diagram, a runbook, a workshop, or a blog post.
I care about being a strong engineer, but the part I enjoy most is multiplying the people around me: making the confusing parts easier to talk about, the repeated parts easier to reuse, and the important decisions easier to revisit later.
Works across
Backend systems, Kotlin/JVM, service design, OpenAPI, Kafka, internal tools, docs, and OSS
Bias toward
Shared understanding, small useful abstractions, boring reliability, and explanations that survive handoff
Track record
A career path through backend systems, platforms, teaching, and tools.
Staff Software Engineer - Payments
Established the Compliance Service as a new domain covering transaction monitoring, screening, and sanction checks – authored the tech spec, interface definitions, and led the ComplyAdvantage integration. Built a cronjob monitoring tool in Backstage aggregating data across multiple systems. Authored operational runbooks for Kafka DLT alerts, settlement reports, and compliance state handling. Member of the architecture team. Drove Spring Boot 3 to 4 migration including upstream contributions to openapi-generator for Jackson 3 support.
Staff Software Engineer - Risk
Co-designed and built the Risk Orchestrator service using hexagonal architecture. Led the Ravelin integration for improved fraud detection, including release planning and cross-team coordination. Authored the Buyer Risk Assessment target architecture. Wrote specs for tokenization, direct debit risk, and recurrent identification. Drove API-first with OpenAPI across all risk services. Led “EDA 2.0” to improve event-driven architecture practices.
Senior Software Engineer - Risk
Built real-time fraud detection features with Apache Flink (velocity features per email/device). Led the graph database POC (Neo4j) for fraud detection, later extended with IBAN integration. Enabled the risk scoring model and introduced provider fraud labelling for refinancing. Applied engineering best practices to Python CI/CD pipelines. Managed Kafka infrastructure via Terraform (topic creation, permissions, DLT retention). Attended Flink Forward 2024 and brought learnings back to the team.
Backend Software Developer
Built a unified money library used across backend and Android. Created an authorization and permissions management library. Designed a sales management platform with clean domain separation. Migrated 6 years of historical data with minimal production impact using a separate deployment strategy. Reduced new service setup from 1 week to 1-2 hours with a repository template. Implemented service-level objective monitoring. On-call for critical payment systems.
Backend Software Developer
Java and Python application development on distributed systems. Refactored a product’s cache system improving performance and reliability. Built an automated release notes generator integrating Python 3 and Jira.
C++/C# Junior Developer
Developed algorithms on next-generation vision processing chips in C++. Created calibration processes for production lines (C++, C#, Python, Matlab). Established production lines in South Korea and China – logistics, equipment setup, and training.
Selected work
Public work that turns repeated problems into reusable material.
01
Upstream contribution
OpenAPI Generator
Upstream Kotlin/Spring generator work that helps teams generate safer service contracts instead of hand-rolling the same integration code.
02
Open source library
ff4k
A Kotlin Multiplatform feature flags library built from a repeated need: simple, explicit flag evaluation with examples people can actually follow.
03
Technical writing / docs
kotlin-design-patterns
Design-pattern examples written for Kotlin developers who want the idea, the tradeoff, and the code without ceremony.
04
Self-hosted tool
TaleKeeper
A personal tool for turning messy live conversation into structured memory, because useful context should not disappear after the session ends.
Writing
Writing is how I turn hard-won context into something other people can reuse.
Oct 17, 2023
Observability in Action: How to Use OpenTelemetry
A hands-on guide to adding distributed tracing and observability to a Kotlin/Spring Boot service using OpenTelemetry and HoneyComb.
Read articleDec 14, 2022
How To Build Your Domain Gateway With OpenApi
An introduction to the domain gateway pattern and a practical tutorial for building one in Kotlin using OpenAPI code generation.
Read articleJun 5, 2024
How to Fix Misconfigurations in RedisTemplate
A practical guide to identifying and fixing common RedisTemplate misconfiguration pitfalls in Spring Boot, with a focus on serialization issues.
Read articleRecommendations
What people notice after working with me.
Blake Irvin
Leading Observability Engineering at SumUp
I’d love to work with Yonatan again. He’s incredibly smart, cares deeply about quality but balances this with delivery speed, and (maybe most importantly) a great human to be teammates with.
Oren Hadry
Former Engineering Manager at Inuitive
I was privileged to have Yonatan on my team for almost 3 years. Yonatan is a dedicated, intelligent, and hard-working team player who played a key role in our team and was the go-to person for almost any problem. I have seen few people who could match his skills at solving technical problems, coding and design.
Shimon Schocken
Computer Science Professor, Reichman University
Yonatan is a highly talented and disciplined software developer, with an excellent background in both computer science and programming. He is a people-person, with remarkable empathy and ability to recognize when and where students and developers need help and further guidelines. He is also a very pleasant and good-spirited colleague.
Contact
If your team needs clarity and code, let's talk.
I am most useful in Staff+ backend roles where the work is not only to deliver a system, but to make the team better at understanding, changing, and owning it.
- Permanent Staff+ backend roles
- Architecture and backend advisory
- OSS, writing, teaching, and collaboration
Based in
Berlin, Germany
Best for
Teams that need a strong engineer who can clarify, build, explain, and multiply the people around him