글

What Is a Service Mesh - and When You Actually Don't Need One

이미지
A service mesh is an infrastructure layer that takes over the network calls between your services: a small proxy runs alongside every service instance, and every request in and out of that instance passes through it. The purpose of a service mesh is to pull retries, timeouts, load balancing, TLS and per-call metrics out of your application code and push them one layer down, where they are configuration rather than library versions. The problem it exists to solve is duplication with drift. In a system with twenty services written in four languages, each one has its own HTTP client, its own idea of a sensible timeout, its own retry behaviour and its own half-finished metrics. Changing any of that globally means twenty pull requests, four library ecosystems and a release train you do not control. The mesh replaces that with a data plane of identical proxies and a control plane that configures them. You get uniform behaviour and a single place to enforce it. You pay for it with two ex...
댓글 쓰기
자세한 내용 보기

What Is Event Sourcing - and When a Plain CRUD Table Is the Right Answer

이미지
Event sourcing is a persistence pattern where the record of truth is an append-only log of everything that happened, not a table of how things currently are. When someone asks what is event sourcing, the short answer is: you store the facts and compute the state, instead of storing the state and throwing the facts away. The problem it exists to solve is information loss on update . UPDATE accounts SET balance = 400 WHERE id = 7 tells you the balance is 400. It does not tell you that it was 500, that a withdrawal of 100 was authorised by a batch job at 03:12, and that a second attempt was rejected. In most systems that history is interesting right up until an auditor, a customer dispute, or a corrupted-data incident makes it essential - and by then it is gone. This page covers the mechanism, the situations where the tradeoff is clearly worth it, and - at length - the much larger set of situations where a normal table with an updated_at column is the correct engineering decision. ...
댓글 쓰기
자세한 내용 보기

What Is a Bloom Filter - and When You Actually Don't Need One

이미지
A Bloom filter is a small, fixed-size bit array that answers one question: "is this key definitely absent, or possibly present?" It never says no when the answer is yes, but it will sometimes say maybe when the answer is no. That asymmetry is the whole product. You trade exact answers for memory, and you get a structure that holds membership information for millions of keys in a few megabytes, with no stored keys at all. The problem it exists to solve is expensive lookups. If checking whether a key exists means a disk seek, a network round trip, or a cross-region query, you want something cheap in front of it that can rule out most of the misses. A Bloom filter is that guard, and its cost is that it lets a small fraction of misses through and can never take a key back out. Concept Bloom filter (BF) Where it sits Data structure - sits in front of an expensive lookup, at the cache or storage layer In one sentence A probabilistic set membership structure that can t...
댓글 쓰기
자세한 내용 보기