标签：#engineering

Every engineer eventually hits this phase: “My design looks okay… but something feels off.” No compile errors. No obvious bugs. But still: responsibilities feel scattered services feel too big entities feel too thin logic feels duplicated boundaries feel unclear This is normal. Because domain modeling is not about getting it right in one attempt. It is about refining structure until the business behavior becomes clear. Step 1 — Start With the Symptom, Not the Code If your design feels wrong, don’t immediately rewrite everything. First identify the symptom: Common symptoms: too many “Manager” services logic repeated in multiple places unclear ownership of rules too many dependencies between modules frequent “if-else explosion” Each symptom points to a specific modeling issue. Step 2 — Check If Invariants Are Scattered Ask: “Where are my business rules living?” Bad sign: Rules inside services + controllers + helpers This leads to: inconsistent behavior duplicated validation broken business guarantees Good design: invariants live close to the entity or aggregate root Step 3 — Check Entity vs Service Confusion A very common issue: Entities become dumb: only fields no behavior Services become overloaded: all logic all rules all decisions This creates: Anemic Domain Model + Fat Services Fix mindset: Entity = owns behavior + protects state Service = coordinates workflows Step 4 — Check Your Aggregate Boundaries Ask: “What must stay consistent together?” If your answer is unclear, you likely have: wrong aggregates or missing aggregates Example problem: Cart and Order sharing logic This causes: inconsistent pricing unclear lifecycle ownership Fix: Cart = intent Order = truth Step 5 — Look for “Hidden Coupling” Hidden coupling happens when: one module depends on internal state of another multiple services modify same data business rules are duplicated across boundaries This leads to fragile systems. Strong design ensures: each domain owns its own truth. Step 6 — Validate Stat

Every team doc tool promises "search everything." Ours did too — and it still didn't answer the question new hires actually ask: not "where is this doc," but "why does this decision look the way it does, and what else does it touch?" We spent the last few months trying to solve that by treating team docs less like a filing cabinet and more like a graph. Here's what we tried, what broke, and what we'd do differently.

Before a young Athenian took his full place in the city, he spent two years in the ephebeia. Training happened in the gymnasion, organized by tribe, the same tribes that would later send him to represent them in the Boule itself. Nobody handed him full standing first and hoped the judgment would follow. This should have been post seven. It’s showing up as sixteen because the gap only became visible once the room was real enough to test against. The Agora described what a Spec Session does. It never asked whether everyone walking into that room shares an accurate picture of what the agent can actually do. Most rooms don’t. Someone watched a demo and thinks the agent can do anything. Someone else got burned by a bad output three weeks ago and doesn’t trust it with anything real. Nobody’s intuition has been tested against the same tasks, and the spec that comes out of that room ends up too ambitious or too conservative depending on whose untested belief happened to speak first. That gap has a name in Athens. The gymnasion existed because nobody was handed a place in the city first and expected to develop judgment on the job. The ephebeia ran two years, training built around a specific fact. Physical readiness and civic judgment weren’t taught in separate places. They happened in the same space, under the same supervisors, organized by the same tribal groupings that would later structure how the city actually governed itself. The same word, gymnasion, ended up naming both the training ground for eighteen-year-olds and the buildings where Plato and Aristotle did their most serious thinking. Academy and Lyceum were gymnasia first. Nobody separated the trial from the reflection. The trial was how the reflection got earned. That’s the part worth taking seriously. Testing a tool and understanding a tool were never two different activities. The testing is how the understanding gets built. A team that reads documentation about what an agent can do has a description. A team tha

İlk insanlı katı-hal uçuşu manşetlere düştüğünde çoğu haber "yeni motor" diye başladı. Oysa bir mühendisin gözünde olay motorda değil. Elektrik motoru bu denklemde en çözülmüş parça: hafif, sessiz, yüksek verimli. Asıl kararların döndüğü yer, o motoru besleyen enerjinin nasıl depolandığı. Bu yazı, duvarın neden onlarca yıl boyunca hep aynı yerde — bataryada — durduğunu sistem mühendisliği açısından ele alıyor. Sistem kısıtı: enerjiyi değil, ağırlığı taşırsınız Bir uçağı tasarlarken bütçeniz enerji değil, kütledir. Depoladığınız her watt-saat bir ağırlıkla gelir ve bu ağırlık kaldırma kuvvetiyle ödenmek zorundadır. Ölçüt enerji yoğunluğu , yani Wh/kg. Kerosen bu metrikte devasa bir avantaja sahip olduğu için jetler onlarca yıl tartışmasız kazandı. Elektrikli havacılığın tüm hikâyesi, bu tek sayıyı yukarı çekme mücadelesidir. Neden hep batarya? Kısır döngünün matematiği Menzili artırmak için daha fazla batarya eklersiniz. Ama batarya ağırdır; eklediğiniz kütle daha fazla kaldırma, dolayısıyla daha fazla enerji ister. O ek enerji için yine batarya eklersiniz ve döngü kendini besler. Buna ağırlığın kısır döngüsü denir ve bir sistem sınırıdır: hücrenin Wh/kg değeri belli bir eşiği aşmadıkça, motoru ne kadar iyileştirirseniz iyileştirin duvar yerinde durur. Kararın kaldıraç noktası bu yüzden hücre kimyasıdır. Kimyayı değiştiren tasarım kararı Bugünün lityum-iyon hücreleri pratikte ~260 Wh/kg dolayında bir tavana oturur. Bu tavanın altında yatan iki bileşen sıvı elektrolit ve grafit anottur. Katı-hal yaklaşımı burada iki radikal karar verir: sıvı elektroliti katı bir iletkenle değiştirir ve anodu lityum-metale taşır. Sonuç ~410 Wh/kg, yani mevcut tavanın %60'tan fazla üstü. Yan kazanım da en az ana kazanım kadar önemli: yanıcı sıvı ortadan kalkınca termal kaçış riski düşer, hücre daha kararlı olur ve 15 dakikanın altında %80 şarj operasyonel olarak mümkün hâle gelir. Bu üç sayı tek başına değil, birlikte anlam kazanır. Havacılıkta bir aracın yerde geçirdiği süre doğrudan m

Suspect-condition workflows are deceptively simple to prototype and surprisingly hard to make defensible . Anyone can flag "this member might have HCC X." Building a system whose output survives a RADV audit is a different problem. This is a walkthrough of the three stages and the engineering decisions that matter at each. Stage 1: Identify Identification is pattern detection over a member's clinical record — labs, medications, prior diagnoses, utilization. Model it as a set of rules or features that emit candidate HCCs: def identify_suspects ( member ): suspects = [] if member [ " labs " ]. get ( " a1c " , 0 ) >= 9.0 and " insulin " in member [ " meds " ]: suspects . append ({ " hcc " : " HCC38 " , " trigger " : " a1c>=9 + insulin " }) if member . get ( " egfr " ) and member [ " egfr " ] < 30 : suspects . append ({ " hcc " : " HCC326 " , " trigger " : " egfr<30 " }) return suspects The temptation is to maximize recall here — flag everything. Resist it. Every unvalidated suspect you generate is downstream work and downstream risk. Stage 2: Validate (the stage that actually matters) Validation attaches evidence to each suspect and scores its defensibility. This is the difference between a documentation opportunity and an audit liability. def validate ( suspect , member ): evidence = collect_evidence ( suspect [ " hcc " ], member ) # labs, rx, prior dx suspect [ " evidence " ] = evidence suspect [ " confidence " ] = score_evidence ( evidence ) suspect [ " defensible " ] = suspect [ " confidence " ] >= 0.7 return suspect Key design rule: a suspect with an empty evidence array should never reach a coder. Make that a hard gate, not a soft warning. Under CMS-HCC V28 and current audit posture, a captured-but-unsupported diagnosis can be extrapolated across a contract into a real clawback — so "defensible by default" is the right engineering stance. Stage 3: Capture Capture routes validated suspects to the right human with the evidence inline, so the clinician or coder can

The cost of writing code dropped; the cost of owning it didn't. A framework for deciding which changes are actually cheap in the AI era. The post The cost of saying yes has changed appeared first on The GitHub Blog .

Everyone recommends ByteByteGo and The Pragmatic Engineer. Don't get me wrong, they're great... but the best engineering writing of the last two years is coming from newer publications nobody's put on a list yet. Here's what survived my filter. I have a rule: if I haven't opened a newsletter in three weeks, I unsubscribe. No guilt, no "maybe later" folder. It's the only way to keep email useful when every engineering team, indie hacker, and AI startup on the planet is running a Substack. That rule has consequences. Over the past couple of years it has killed off almost every famous-name newsletter in my inbox — not because they got worse, but because they got comfortable. Meanwhile, a new generation of engineering publications launched around 2023–2024 started earning their slot every single week. They're smaller, sharper, and written by people still close to the work. The other thing my rule revealed: AI engineering quietly became its own discipline. Not "AI news" — there are a thousand newsletters rehashing model launches. I mean the craft of building production systems on top of LLMs: agents, evals, brownfield integration, governance, cost. That coverage barely existed two years ago. Now it's the most valuable section of my inbox, which is why it leads this list. So here's what survived. Twenty-six newsletters, organized by topic, heavy on publications you haven't seen on every listicle. Steal the whole list. 🤖 AI Engineering & Production AI Two years ago this category didn't exist. Today it's the most important one here, because building with LLMs in production is genuinely different work — different failure modes, different economics, different skills — and general engineering newsletters mostly aren't covering it. Latent Space — swyx & Alessio Fanelli. swyx literally coined "AI engineering" as a discipline, and this is its watering hole: podcast, essays, and the AINews digest covering frontier models, agents, and the career path itself. The anchor of the categ

I've been tuning Codenames AI , a small web game where an LLM plays Codenames with you. Clue generation is tightly constrained: one word, a count, optional intended targets, JSON on the wire, then deterministic validation before anything reaches the board. As the project started attracting regular players, I wanted to improve the gameplay experience without blowing out costs. Moving one model generation from gpt-4o-mini to gpt-5-mini was my first instinct. The default reasoning setting made responses an order of magnitude slower for this workload. Minimal reasoning looked like the obvious compromise: newer model, responsive gameplay. I expected to compare clue quality, latency, and cost while the surrounding prompt, validator, and consumer contracts stayed put. That last part was wrong. The experiment stopped behaving like an A/B test What showed up was structural, and it showed up in places that had been stable for months. Validation failures started rising. Retries started rising. Entire candidate batches started failing before the game ever saw a clue. The sharpest signal came from a clue-selection path that had run untouched for months, and it hard-failed for the first time. They weren't latency regressions so much as architectural ones. It is easy to read that as "minimal reasoning made the model worse." More often, the failures were exposing gaps in contracts that had looked fine under the previous model. What each failure actually invalidated Eventually every failure traced back to one of three layers: Prompt contracts ask for exactly count targets and, in batch mode, several distinct candidates. Deterministic validators reject target/count mismatches and filter invalid candidates before anything downstream runs. Downstream consumers only see survivors. Empty batches retry with rejection feedback, then fall back if needed. Those layers share one job: enforce the same invariants. The failures below cut across all three rather than mapping one to one. Side comm

Ben O'Mahony discusses building custom AI-powered Language Server Protocols (LSPs) that go beyond standard rule-based checkers. He explains how to instrument AI agents natively with OpenTelemetry to track concrete user actions (accepting, dismissing, or regenerating code fixes) as implicit labels, creating a continuous data flywheel to distill frontier capabilities into cheaper, local SLMs. By Ben O'Mahony

Most people, when a prompt stops working, write more . They add clarifications, repeat instructions in different words, hedge against edge cases they haven't encountered yet. The prompt doubles in length. The output gets worse. This is the opposite of what you should do. A long prompt is not a precise prompt. It is an ambiguous prompt that happens to have a lot of words in it. Every sentence that does not tightly constrain the output is a sentence that dilutes the sentences that do. Why Long Prompts Underperform When a language model processes your prompt, it attends to all tokens simultaneously — but not equally. Attention is probabilistic. Instructions that are buried in filler, repeated in slightly different forms, or surrounded by low-information prose get proportionally less weight. The model's ability to track which constraint takes precedence over which degrades as the signal-to-noise ratio of the prompt drops. In quantitative trading, the signal-to-noise ratio (SNR) is the single most important property of any strategy signal — a strategy that works in backtesting but fails live is almost always a noise problem, not a signal problem. The same principle applies directly to prompts. Every redundant qualifier, every throat-clearing sentence, every hedge phrase is noise riding on top of your actual instruction signal. The model's attention mechanism cannot distinguish intent from filler. It weighs them together, which means your real constraints compete for attention against your own verbal padding. A concrete way to see this: take a 600-word prompt and a 120-word prompt that contains the same core logic. The 120-word version, if well-constructed, will frequently outperform the 600-word one. Not because brevity is a virtue in itself, but because removing the surrounding noise forces the remaining tokens to do all the work — and they accumulate proportionally more attention weight. This is not speculative. It is the same mechanism behind why prompt drift happens

The Quest Begins (The "Why") I still remember the first time I walked out of a coding interview feeling like I’d just lost a lightsaber duel. The problem was a simple array‑rotation task, but I dove straight into typing, eyes glued to the screen, and barely said a word. When the interviewer asked, “What are you thinking right now?” I froze, mumbled something about “just trying to get it done,” and watched the seconds tick away. The feedback later? “Great coding skills, but we couldn’t follow your thought process.” That moment stung because I knew I could solve the problem—I just hadn’t learned how to show my thinking. After a few more silent attempts, I realized the interview isn’t a solo boss fight; it’s a co‑op mission where the interviewer wants to see how you navigate the terrain. If they can’t hear your internal monologue, they have no way to gauge your problem‑solving instincts, communication style, or ability to catch mistakes early. I went on a quest for a repeatable, low‑effort way to narrate my thinking without turning the interview into a monologue. What I found was a three‑step verbal framework that felt like unlocking a new Force power—simple, repeatable, and surprisingly effective. The Revelation (The Insight) The technique I now swear by is State → Plan → Execute . At each stage you say out loud exactly what you’re doing, using a tight, repeatable script. It’s not about over‑explaining; it’s about giving the interviewer a clear map of your mind. Here’s the exact wording I use, broken down by phase: State – Clarify the problem, assumptions, and constraints. “Okay, so we need to rotate an array to the right by k steps. I’m assuming k can be larger than the array length, so I’ll use modulo to normalize it. The array can contain any integers, and we should aim for O(n) time and O(1) extra space.” Plan – Outline the high‑level approach before writing a line of code. “My plan is to use the three‑step reversal algorithm: reverse the whole array, then reverse

Metron was the Greek word for a measure: the standard you judge a thing against. It gives us metric, and metronome. Pick the wrong metron and everything you count against it comes out wrong, no matter how carefully you count. Ask most teams how they know AI adoption is working, and the answer is some version of: we’re shipping more. More PRs, more tickets closed, more velocity on the board. None of those numbers were ever measuring what people thought they were measuring. They were proxies, and bad ones, for whether the team was creating value. AI didn’t break that. It just made the proxies lie louder. An agent can produce PRs faster than any team can review them. It can close tickets all day. None of that tells you whether the thing built was worth building, or whether it fixed the actual problem, or whether anyone downstream is better off. Burning tokens isn’t the same thing as creating value. It just looks the same on a dashboard built to reward the first thing. The same DORA numbers I pointed at earlier are blunt about it: individual output climbs while delivery throughput and stability drop. Same bottleneck, counted at the wrong end . This is Theory of Constraints in one sentence: speeding up a step that wasn’t the bottleneck doesn’t speed up the system. It just piles more work in front of whatever the real bottleneck is. Implementation used to be the constraint. Now it isn’t. Review is. Coordination is. Making sure everyone agrees on what “done” even means is. Agents made the fast part faster and left the slow part exactly where it was, except now it’s buried under more output arriving to be reviewed by fewer people who understand any of it. Measuring individual speed after that shift is measuring the wrong clock. The team can be faster and worse off in the same quarter. The instinct, when this gets noticed, is to add another skill to the agent. Automate the review step too. Automate the coordination. Whatever’s slow, throw a capability at it. That doesn’t fix

Your data warehouse has a table called orders . It has columns like amount , status , created_at , and customer_id . Now three people ask "What was Q1 revenue?" The analyst writes SELECT SUM(amount) FROM orders WHERE created_at BETWEEN '2026-01-01' AND '2026-03-31' . The data engineer adds WHERE status = 'completed' . Finance excludes refunds and trial conversions. Three queries, three numbers, one question. Nobody is wrong. They just defined "revenue" differently. Multiply this by every metric in your organization, every team that queries the warehouse, and every tool that displays a number. That's the problem. A semantic layer solves it by defining each metric once, in one place, and serving that definition to every consumer. What is a semantic layer? A semantic layer is a metadata layer between your data warehouse and every tool that queries it. It defines business metrics, maps them to SQL, and exposes them through APIs. Instead of every consumer writing its own query, they all reference the same definition. When someone asks for "revenue," the semantic layer knows that means: SUM ( CASE WHEN status != 'refunded' AND type != 'trial' THEN amount ELSE 0 END ) That definition lives in one place. Dashboards, APIs, AI agents, and ad-hoc queries all use it. Change the definition once and every consumer gets the updated calculation. No Slack thread asking "which number is right." No detective work tracing a wrong number back to a stale query in a notebook somewhere. The core components of a semantic layer: Metrics (measures). The numbers you aggregate: revenue, order count, average deal size. Each metric has a fixed SQL definition. Dimensions. The columns you filter and group by: date, status, category, region. Dimensions define the axes of analysis. Relationships (joins). How tables connect: orders belong to customers, products belong to categories. Defined once, reused by every query. Access rules. Who can see what. Row-level security, tenant isolation, role-based ac

"We need real-time analytics" is one of the most common requests in data engineering. It's also one of the most misunderstood. When the VP of Sales says "real-time," they usually mean "faster than the dashboard that refreshes overnight." When the CTO says it, they might mean sub-second event streaming. The gap between those two definitions is a 6-month infrastructure project. Most teams don't need true real-time. They need fast enough. And "fast enough" is achievable with pre-aggregation caching at a fraction of the complexity and cost of a streaming architecture. What is real-time analytics? Real-time analytics means querying data with minimal latency between when an event happens and when it's visible in your analytics. The spectrum: Freshness Latency Architecture Use case True real-time < 1 second Event streaming (Kafka, Flink) Fraud detection, stock trading, live monitoring Near real-time 1-60 seconds Micro-batch or streaming Operational dashboards, alerting Frequent refresh 1-60 minutes Scheduled refresh + caching KPI dashboards, AI agent queries Batch Hours to daily Scheduled ETL Board reports, monthly summaries Most analytics use cases fall in the "frequent refresh" category. Revenue by region doesn't need sub-second freshness. Active users in the last hour doesn't need event streaming. A pre-aggregation cache that refreshes every 15 minutes covers 90% of what teams call "real-time." When you actually need real-time True real-time analytics (sub-second latency from event to query result) is worth the infrastructure investment when: Fraud detection. Every second of delay is potential fraud that slips through. Live monitoring. Server health, API error rates, active user counts for live products. Trading and pricing. Financial instruments where stale data means wrong prices. Live events. Streaming metrics during a product launch, marketing campaign, or live broadcast. If you're in one of these categories, you need an event streaming architecture: Kafka, Flink, M

Ruth Linehan explains how migrating high-performance caching services from Kotlin to Rust shattered internal preconceptions around delivery velocity and engineering overhead. She discusses the ergonomics of the Rust borrow checker, shares how compile-time safety shortens the developer feedback loop, and profiles how tools like Criterion and flamegraphs optimize concurrent code paths. By Ruth Linehan

A three-person agency received a $14,000 AWS bill in one day after attackers extracted static access keys and burned Claude invocations on Bedrock. Combined with May's DN42 incident, where an autonomous agent provisioned $6,531 of oversized infrastructure in 24 hours, practitioners warn that cloud billing lags roughly a day behind agent-speed spend. By Steef-Jan Wiggers

Every organisation that has run a significant software system for more than a few years has felt a version of the same thing: a change that should have taken days takes months, nobody can quite explain why, and the explanation that eventually gets offered — the domain is complex, the requirements changed, the previous team was careless — is almost never checked against an alternative approach for the software architecture or alternative framework choices, because the alternative was never built. There is no possible comparison to determine the solution chosen is a good one and there is no benchmark to measure "fit for purpose." This is the unfalsifiability problem, and it is worth stating plainly before anything else in this piece, because it is the reason the cost described below is so rarely traced back to its actual cause. Every system is built once. There is no version of your platform built the other way, running alongside it, that anyone can compare it to. So when a system works, the approach that produced it gets read as validated. When a system becomes expensive to change, the cost gets attributed to anything except the structural decision that caused it — because that decision was made years ago, by people who may have moved on, and there is no control group to prove that the structure was the variable that mattered. That absence of a control group is not a minor academic point. It is the reason a specific, avoidable pattern of cost has been able to spread through the industry for decades, get taught in courses, get validated in interviews, and still never be clearly named as a mistake. This article is an attempt to name it — and to offer something more useful than a diagnosis: a way to check, this week, whether it applies to you. The Villain: Process Over Product Ask almost any team building a significant piece of software what the goal of the project is, and the honest answer, more often than anyone would like to admit, is not "build the best-fitting prod

Last week an AI-generated GPU kernel ran 18.71× faster than an optimized PyTorch baseline. The model—Fable 5—didn't just edge past the human implementation. It lapped it. Claude Opus 4.8 reached 14.4×. GLM-5.2 hit 11.14×. GPT-5.5 managed 4.34×. Fable's kernel was in a different tier entirely. The exciting read: AI is starting to improve the low-level machinery that makes AI itself cheaper and faster. Specialized performance work that once required rare expertise just got dramatically easier to explore. The uncomfortable read: what happens when the best implementation is also the one nobody on your team would have written—or can fully explain? That question is about to land on every engineering team that ships AI-generated code. The Benchmark Problem A benchmark shows the kernel ran fast under tested conditions. It doesn't show: How it behaves across different GPU hardware How it handles numerical edge cases What happens under months of production changes Whether it degrades gracefully when inputs shift The person who wrote it can't answer these questions either. The AI generated this code through a process that doesn't leave a reviewable chain of reasoning. There's no commit message that says "I chose this approach because X." So the reviewer's job just got harder—not easier. The Real Shift I've been watching this pattern across engineering teams this year. The argument is moving from "can AI generate working code?" to "can our org absorb generated code without breaking quality, morale, or judgment?" The GPU kernel story makes the tension concrete: One side says the code ran, it was measured, it won. Stop moving the goalposts. The other side says somebody still has to know where it can fail and take responsibility when it does. Both are right. AI can make implementation cheaper while making proof more expensive. Senior engineers may write less code but spend more time designing adversarial tests, checking assumptions, planning rollbacks, and deciding whether an impr

​I. The Terminal Velocity of Disembodied Intelligence ​The current paradigm of artificial intelligence is approaching a fundamental cognitive ceiling. We have built vast, sprawling minds, yet we have trapped them in sensory deprivation chambers. Today’s Large Language Models and industrial robotics operate under a fatal flaw: the reliance on linear, arbitrary tokenization. Traditional AI chops raw text into disconnected, non-semantic fragments, wasting immense computational memory tracking the mere phonetic order of spelling and grammar. ​Simultaneously, industrial machines navigate the physical world through siloed sensor pipelines. They process light, space, and kinetics as heavy, raw digital arrays, relying on brute-force algorithmic equations to stitch reality together. This is not intelligence; it is computational exhaustion. To achieve true artificial general intelligence, the machine must stop reading about the world and begin to inhabit it. ​II. The Biological Imperative ​Nature solved the hardware-software integration problem millions of years ago. Human biology remains the ultimate benchmark for flawless, metabolic efficiency. Our somatosensory system does not wait for a central brain to read a text string before pulling a hand away from a fire; it processes physical feedback in milliseconds through decentralized neural highways. ​Human cognition leverages cross-modal integration within the angular gyrus, allowing visual data to be instantly cross-referenced with kinesthetic feedback to trigger anticipatory motor reflexes. Furthermore, biological intelligence is inherently tied to physical survival. We manage thermodynamics through a centralized hypothalamic thermostat, protecting the body from cellular destruction, while routing ambient light data to deep-brain structures to drive a natural circadian rhythm. True AGI requires this exact synthesis of abstract thought and biological mechanics. ​III. The Logographic Paradigm Shift ​To bridge the gap between

"We're using Kafka with exactly-once semantics, so we don't have to worry about duplicates." I've heard this in architecture reviews, design docs, and postmortem explanations. It represents a misunderstanding of what Kafka's exactly-once guarantee actually covers, and the gap between the promise and the reality has caused real production incidents. What Kafka's Exactly-Once Actually Covers Kafka's exactly-once semantics (EOS), introduced in 0.11.0, operates at two levels: Producer idempotence ( enable.idempotence=true ): The producer assigns each message a sequence number. The broker deduplicates messages with the same producer ID and sequence number. This prevents duplicates caused by producer retries — the message lands in the Kafka partition exactly once, regardless of retry count. Transactions ( transactional.id ): Allows a producer to write to multiple partitions atomically. Either all writes commit or none do. Combined with isolation.level=read_committed on consumers, readers only see committed transactions. Together, these give you exactly-once message delivery within the Kafka cluster. What Exactly-Once Does Not Cover Here's the boundary that engineers miss: Kafka's exactly-once guarantee is scoped to the Kafka cluster. The moment your consumer does anything outside Kafka — writes to a database, calls a REST API, publishes to a cloud queue — you're outside the transaction boundary. Consider a typical consumer: consumer . poll ( records ); for ( record : records ) { database . save ( process ( record )); // External write — outside Kafka transaction } consumer . commitSync (); If the application crashes after database.save() but before commitSync() , Kafka re-delivers the message. The consumer reprocesses it. The database now has two writes for the same event. Enabling producer idempotence on the consumer's Kafka writes does not fix this. The Patterns That Actually Give You End-to-End Safety Idempotent Consumers Design consumer processing logic to be idempote