Engineer Brief | Tech News, Deconstructed by a 10-Year Dev

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...

Deciding when to use GraphQL over REST API comes down to one question: who decides the shape of the response, the server or the client? In REST, the server owns it — each endpoint returns a fixed document, and the client takes what it gets. GraphQL inverts that: the client sends a query naming the exact fields it wants, and the server assembles a response with that shape and nothing else. The problem this exists to solve is client/server response mismatch at scale . When you have one backend and one web client, the server can just return the right fields. When you have a web app, an iOS app, an Android app, and a partner integration all reading the same data with different needs, you either ship a fixed endpoint that overserves everyone, or you accumulate /users/:id/mobile-summary -style variants that nobody dares delete. GraphQL trades a fixed contract for a flexible one. That flexibility is real, and so is the operational bill it comes with: your performance and security story mov...