ThePolymathicEng

Official account of the Polymathic Engineer newsletter, written by @franc0fernand0. Algorithms, distributed systems, and software engineering. Subscribe here:

[Fernando @Franc0Fernand0]

If you want to get better at algorithms and data structures, read these 12 articles: ↓

[Fernando @Franc0Fernand0]

Ever wonder what your database actually spends its time doing?

Most of us assume it's busy reading and writing rows. The reality is stranger.

There's a classic paper from Mike Stonebraker that profiled a traditional transactional database down to the individual CPU instruction.

The finding: less than 10% of instructions do real, useful work. The other 90%+ is pure overhead, split fairly evenly between four things:

1. Taking care of buffers (moving pages from a cache pool to the disk)

2. Locking (row-level locks that manage multiple transactions at the same time)

3. Latching (lightweight locks keep the internals of data structures safe)

4. Logging (writing down operations before they happen so they can be recovered)

At first this is depressing. There's no single bottleneck to fix. Every one of those four is essential to how a traditional database works. But flip it around and it becomes one of the most interesting results in database design.

If those four sources of overhead are what's eating your CPU, what happens if you remove the need for them?

- no buffers -> keep the database entirely in memory
- no locking or latching -> single-threaded system
- no logs -> replication.

That's exactly the bet behind H-Store, and later VoltDB. Give up a bit of flexibility, and you unlock performance that's hard to believe.

The lesson I keep coming back to: a lot of "overhead" in systems isn't waste, it's the price of a feature you assumed you needed. Question the feature, and the overhead disappears with it.

[Fernando @Franc0Fernand0]

DFS is the pattern you reach for when you need to find a path, check if something is reachable, or explore all possible paths through a structure.

The main idea behind it is simple: start at a node, visit its children or neighbors recursively, and go as deep as possible before backtracking.

When you reach a dead end, you return and try a different path. You keep doing this until you find what you are looking for or you run out of paths to explore.

The same approach works on trees, graphs, and many problems that can be represented as graphs, even if they don't look like one at first glance:

- When it comes to trees, the pattern is simple. You traverse nodes recursively, returning results as you come back up.

- When dealing with graphs, you have to keep track of visited nodes to avoid cycles.

- In matrix problems, cells are nodes and neighboring cells are neighbors. The logic is always the same.

Read about all these DFS variants in detail in the latest article on the @EngPolymathic

[ThePolymathicEng @EngPolymathic]

The 177th issue of the Polymathic Engineer is out.

This week, we talk about Depth-First Search:

- The Core Pattern
- Finding Paths
- Handling Cycles
- Finding All Paths
- Matrices as Implicit Graphs -
- When DFS Applies

Read it here:
https://t.co/jpa0G0cmnw

[Fernando @Franc0Fernand0]

A service mesh can do a lot.

Every microservice system has to deal with traffic management, reliability, security, and observability.

A service mesh addresses these challenges in one place, in the same way, no matter what programming language each service is built in.

This is the real value of the pattern: it keeps the application teams from having to write the same networking code over and over again. Instead, they can focus on solving the real business problems.

But this has a price. The added latency, resource overhead, and operational complexity are not small problems. They mean that a service mesh is not a good choice for small systems or teams that are fresh out of the gate.

You should switch to a mesh only when you have enough services and complexity to make the trade-off worthwhile. And when you do, the choice amongst Istio, Linkerd, Consul, and App Mesh comes down to the features you need, how much work you are willing to do, and where your services are running.

The latest article by the Polymathic Engineer first breaks down the benefits, then the trade-offs, and finally takes a quick look at the most typical service mesh implementations.

[ThePolymathicEng @EngPolymathic]

The 176th issue of the Polymathic Engineer newsletter is out.

This week, we keep talking about service mesh:

- Traffic management and routing
- Reliability
- Security
- Observability
- When a mesh isn't worth it
- A tour of popular meshes

Link:
https://t.co/vQLpSZlCGo

[Fernando @Franc0Fernand0]

Moving from a monolith to microservices solves some problems but creates new ones.

A call to a function inside a monolith is now a call between two services over the network. And network calls are a whole other story.

They can be slow, break, or get lost. We need to think about things like how to spread the load across service instances, how to retry failed requests, how to encrypt data between services, and which service can call which.

These are the kinds of problems a service mesh is built to solve. The application code no longer cares about networking concerns. Instead, there is a separate layer of sidecar proxies coordinated by a control plane.

At a high level, a service mesh is a dedicated layer that sits between your services and handles all the network traffic between them.

The application code makes a standard HTTP or gRPC call, and the mesh does the heavy lifting behind the scenes by handling encryption, timeouts, retries, and service discovery.

In the latest issue of the @EngPolymathic, you can read a breakdown of the fundamentals of service mesh: why the pattern exists, what it actually is, and how its architecture works.

[ThePolymathicEng @EngPolymathic]

The 175th issue of the Polymathic Engineer is out.

This week, we talk about service mesh:

- Why we need a service mesh
- What a service mesh is
- The sidecar pattern
- Data plane and control plane
- Where a service mesh is deployed

Link:

https://t.co/n6RijelWQ0

[Fernando @Franc0Fernand0]

Divide and conquer is a great technique for designing algorithms.

The basic idea is simple: split the problem into smaller subproblems, solve them independently, and combine the results.

The thing is: how do we split the input? There are two possibilities:

- If the split point is fixed, we know exactly where to divide the input. Binary search always splits in the middle. Merge sort always divides in the middle. Here, the only decision is which half to look at in the case of binary search, or how to merge the halves in the case of merge sort.

- If we do not know where to split. We have to try every possible split point, solve both sides for each split, and see which one gives us the best result. This comes up in grouping problems, where we need to find all ways to partition an input or the optimal way to group elements together. A good example is the unique BST problem.

If you want to go into more detail, you can find a great breakdown of Divide and Conquer in the latest issue of
@EngPolymathic

[ThePolymathicEng @EngPolymathic]

The 174th issue of the Polymathic Engineer is out.

This week's article is about divide and conquer:

- Core Pattern
- Fixed Splitting: Binary Search
- Trying All Splits: Unique Binary Search Trees
- Other Examples
- When Divide and Conquer Applies

Link:
https://t.co/eoOI23IipQ

[Andrej Karpathy @karpathy]

Personal update: I've joined Anthropic. I think the next few years at the frontier of LLMs will be especially formative. I am very excited to join the team here and get back to R&D. I remain deeply passionate about education and plan to resume my work on it in time.

[ThePolymathicEng @EngPolymathic]

The 173rd issue of the Polymathic Engineer is out.

This week's article is about Bloom Filters:

- How they differ from hash tables
- How they work
- Why are there no false negatives
- Why are there false positives
- Tuning the filter
- Use cases

Link:
https://t.co/tu6uREenNH

[Fernando @Franc0Fernand0]

To build a CS skillset that can't be replaced by an AI, you have to learn fundamentals.

That lets you do things that an AI still can't, because your brain learn how to think and work.

If you want to get better at fundamentals, read these 16 articles: (links below) ↓

[Fernando @Franc0Fernand0]

Many combinatorial problems require you to generate all the possible permutations of a set of items.

But how can you do that? How do you know which item comes next?

There are two different approaches you can use:

1. Keep a set of available items. At each step, pick one item from the set, add it to the current permutation, remove it from the set, and recursively find all permutations of the remaining items. When there are no remaining items, you have built one complete permutation.

2. Divide the array into two parts using an index. All the items before the index already belong to the permutation we are generating. The items from the index onward are the pool of items we can still choose from. At each step, we swap an item from the available portion into the current position and then move to the next index.

You can read a step-by-step explanation of the two approaches and how you can apply them to real problems in the latest issue of @EngPolymathic

[ThePolymathicEng @EngPolymathic]

The 172nd issue of the Polymathic Engineer is out.

This week, we talk about algorithms you can use to generate permutations:

- Ordering Pattern
- Swap-Based Approach
- Specific Length
- Handling Duplicates
- BSTs Orderings
- When Ordering Applies

Link:

https://t.co/skfJZO0qDj

[Fernando @Franc0Fernand0]

In distributed systems, failures can happen all the time, everywhere.

What's important is how to keep those failures from spreading between services.

There are two kinds of patterns to know:

1. downstream patterns protect a service when one of its dependencies fails or slows down:

- Timeouts stop calls that never return
- Retries help get around short-lived issues
- Circuit breakers take over when services are down for a longer time.

2. upstream patterns protect a service when its callers send more traffic than it can handle:

- Load shedding helps manage excess traffic that a server can't handle
- Load leveling helps smooth traffic spikes through a messaging channel.
- Rate limiting puts a cap on the number of requests a single caller can make.
- The constant work pattern keeps the amount of work the same, no matter what happens, so there are no surprises.

None of these patterns works on its own. The true value comes from putting them together in a way that meets your system's needs.

You can read a step-by-step breakdown of these patterns in the latest issue of @EngPolymathic

[ThePolymathicEng @EngPolymathic]

The 171st of the Polymathic Engineer is out.

This week, we discuss patterns that stop failures from spreading between services:

- Timeouts
- Retries
- Circuit breakers
- Load shedding
- Load leveling
- Rate limiting
- Constant work

Link:

https://t.co/wpJI3M8S38

[Fernando @Franc0Fernand0]

"Nobody is learning C++ in 2026" is just bullshit.

C++ is a programming language that is still highly in demand.

If you want to learn or get better at C++, check the following resources: (details below) ↓

[Fernando @Franc0Fernand0]

If you are a software engineer who is serious about getting better at data structures and algorithms, read these 16 curated articles: (links below) ↓

[Fernando @Franc0Fernand0]

Linear regression is a fundamental algorithm in machine learning.

Even though it is simple and intuitive, many engineers treat it as a black box. They call a function from scikit-learn, get a result, and move on.

But understanding what happens under the hood is critical because linear regression is the building block for more complex models like neural networks.

In the article below, I broke down linear regression from the ground up. I started with a simple example to give you a sense of how it works, and then I went into the math and algorithms that make it all possible:

- what features, weights, and bias are
- how to find the best line
- how to measure if a model is good
- using multiple features
- capturing complex patterns with a polynomial
- real-world applications
- hands-on examples

Read it in the latest issue of @EngPolymathic