Károly Bödei seated in a plaza before a grand Budapest building

Budapest, Hungary

Károly Bödei

Engineering Leader

Craft Code Enjoyer with a bit of AI flavour.

Get in touch Download CV

Who I am

About

Curious engineering leader who enjoys diving into technical literature, experimenting with new technologies, and thinking about scalable systems. These days I'm exploring Go, diving into distributed design hell, taming AWS, and pursuing ikigai through engineering.

0+

Years in software

0+

Shipped projects

0+

Articles read on daily.dev

Languages

  • HungarianNative
  • EnglishProfessional working proficiency
  • GermanBasic

Where I've worked

Experience

Building software since 2016 — a few highlights below.

Backend Chapter Lead · Trendency Online

Apr 2024 – Present

Budapest, Hungary

  • Lead the backend team (~25 engineers), owning engineering standards, architectural direction, and capability development across multiple teams delivering high-impact digital products.
  • Drove company-wide adoption of AI-assisted development — evaluated and rolled out AI coding tools, and set usage standards and guardrails across the SDLC. Proved the methodology hands-on — personally shipped several production projects end-to-end using AI-assisted development.
  • Defined and enforced development best practices and quality benchmarks through the SDLC
  • Drove Developer Experience (DX) improvements across tooling and workflows

Senior Software Engineer · Trendency Online

Jun 2022 – Apr 2024

Budapest, Hungary

  • Backend engineer focused on architecture-heavy product development in an enterprise-scale environment.
  • Designed and implemented a modular CMS framework based on CQRS and Hexagonal Architecture.
  • Built scalable systems serving high-traffic news portals and campaign platforms with ~2M daily visitors.

What I've built

Projects

today

News-intelligence platform using microservices and AI processing to aggregate and analyze news.

MicroservicesAIGo

rss2msg

Go service for polling RSS/Atom/JSON feeds with configurable message routing.

GoRSSMessaging

mario

CLI for OpenAPI specification analysis and orchestration.

CLIOpenAPITooling

Tippmix Radar

Real-time sports-betting platform built on AWS.

AWSRealtimePlatform

Nova

Multisite CMS with event organization, built on Google Cloud Platform.

GCPCMSMultisite

30+ more projects, under NDA

Confidential client and internal systems I can't show publicly — happy to walk through them in person.

rss2msg

A feed-polling daemon that turns any RSS, Atom, or JSON feed into messages on the queue, database, or webhook you already run.

github.com/IAmBod/rss2msg
Pipeline diagram: feeds flow through a fetcher issuing conditional GETs, a detector hashing each item, and a canonical change envelope, out to eighteen sink drivers. A coordinator gates each poll cycle above the fetcher, and a shared state store holding seen items and HTTP validators sits below the fetcher and detector.
feeds → fetcher → detector → envelope → sinks, gated by a coordinator and backed by a shared state store.
  • 18Sink drivers
  • 5Coordinator backends
  • 4State stores
  • Go
  • Kafka
  • AMQP
  • NATS
  • Postgres
  • gRPC
  • OpenTelemetry
  • Docker

The problem

Anything that reacts to a feed ends up rewriting the same loop: poll on a timer, work out which items are genuinely new, push them somewhere. The polling and the change detection are identical every time — only the destination differs, Kafka in one system, a Slack webhook in the next, a Postgres table in the one after that. So the fiddly part gets rewritten per project — conditional requests, stable item identity, content hashing, retries — and quietly gets slightly wrong each time.

What I built

One Go daemon that owns that loop and treats the destination as configuration. Feeds are declared in YAML; each cycle issues a conditional GET, short-circuits on a 304, hashes every item, classifies it as new, updated, or unchanged, and publishes a canonical change envelope to any of eighteen sink drivers — Kafka, three AMQP/RabbitMQ flavours, SQS, SNS, DynamoDB, Pub/Sub, NATS, Azure Service Bus, Cosmos DB, Dapr, Postgres, gRPC, HTTP webhooks, an RSS feed of its own, or a composite fanning out to several at once. It runs as a long-lived service or a single-shot job, with per-sink retry, dead-letter routing, and OpenTelemetry throughout.

The hard part

Running more than one copy. The obvious design elects a leader and lets it own the feeds, which buys a failover story nobody enjoys operating. Instead every instance is identical, and a coordinator gates each feed for each cycle — Postgres session advisory locks, a Redis TTL lease, DynamoDB or Cosmos DB — with instances that lose the gate skipping the cycle silently. A crash releases the lock or expires the lease, so recovery needs no election and no human. The honest cost is at-least-once delivery: state is committed only after every sink has taken the change, so a crash mid-publish means a re-send. That is written down in the docs, together with the dedupe key consumers need, rather than dressed up as exactly-once.

Tippmix Radar

A companion app for Hungary's betting-shop sports betting: scan a paper slip, then follow it live.

tippmix.hu/mobil/radar
Tippmix Radar store graphic: a phone showing the app's radar logo on a green screen

Role: Architect and backend engineer

  • ~150kDaily users
  • ~2MPush notifications / day
  • ~50kTransactions / day
  • ~20GBData payload / day
  • AWS
  • Real-time pipelines
  • Push notifications
  • Provider integrations

The problem

Tippmix betting is played on paper. You fill in a slip at a lottery shop, walk out with it, and then have no idea how it is doing until you check the results yourself and work out whether anything won. The physical slip is the whole product, and it gives no feedback.

What I built

An app that scans the printed slip and turns it into something live. Once a slip is registered it tracks every event on it, evaluates outcomes as results land, and pushes a notification the moment something changes — a goal, a card, a half-time whistle, or a slip settling as a winner. Around it sit an events and odds browser and a map-based shop finder for placing the next one.

The hard part

Fan-out under a deadline. Sports data arrives in bursts from external providers, and a single goal in a well-backed match can mean notifying a large share of the user base at once — roughly 2M notifications a day in total, all of which are worthless if they arrive after the user has seen the score elsewhere. The pipeline had to ingest ~20GB of provider payload daily, resolve it against ~50k transactions, and fan out without queueing behind itself.

Two phones showing the app's saved betting slips and its upcoming football events list with odds
Registered slips and the events browser.
Two phones showing per-event notification settings and a lock screen stacked with win alerts
Per-event alert settings, and the push fan-out arriving.
Two phones showing boosted odds on football fixtures and an in-app prize campaign
Boosted odds and in-app campaigns.

Under the hood

Skills

The stack behind everything above — including the 30+projects I can't show publicly.

Leadership

Team leadershipMentoringTechnical strategyCross-team delivery

AI-assisted Development

Agentic DevelopmentAgent SkillsMCPsPluginsClaude CodeClaude Design

AI

LangChainLangGraphLangFuse

Languages & Frameworks

TypeScriptGoPHPJavaPythonSQLNestJSReactSymfonyLaravel

Cloud & Infra

AWSGCPAzureKubernetesDockerLinux

DevOps

GitHub ActionsGitLab CITerraformAnsibleHelmArgoCDGitGitOps

Backend

MicroservicesEvent-driven systemsRESTOpenAPI

Data & Messaging

PostgreSQLMongoDBKafkaRabbitMQ StreamsRedpanda ConnectElasticsearch

Observability

GrafanaPrometheusOpenTelemetryKibana

…and plenty more

New languages, tools, and platforms with every project — this is a snapshot, not the whole toolbox.

Where I studied

Education

MIT Professional Education

2026 – Present

Professional Certificate · Applied AI and Data Science

Online · Cambridge, MA

Budapest University of Technology and Economics

2017 – 2022

BSc · Computer Science Engineering

Budapest, Hungary

  • Major in Software Engineering.
  • Minor in Modern Platforms — Kubernetes and observability.

Kölcsey Ferenc Gimnázium

2012 – 2017

English Bilingual and Multilingual Education

Zalaegerszeg, Hungary

Recognition

Awards & Certifications

Awards

Professional Leader of the Year

2025

Trendency Online

Backend Engineer of the Year

2023

Trendency Online

Certifications

Jira Service Management

2023

META-INF · Atlassian

Jira and Confluence Basics

2022

META-INF · Atlassian

Say hello

Get in touch

Open to new roles

I'm listening for engineering leadership roles — backend, platform, or building out a team's AI-assisted development practice. If you're hiring for something like that, I'd like to hear about it.

Interested in working together or just want to talk shop? Reach out on any of these.

Emailinfo@iambod.devGitHub@IAmBodLinkedInin/iambod

Prefer a document? Download the CV as a PDF.