Daily 326 streak

Nice problem, graphs (in some sense), not very very hard, but pretty tough. Recommend, it uses 2 common patterns.

https://leetcode.com/problems/find-the-safest-path-in-a-grid/description/?envType=daily-question&envId=2026-07-01

#daily #medium #pattern

From now on I switch pattern Daily (X/373 streak until LC cap) to Daily X streak as we have got cap, and I don't have much goal now except just keep going and keep skill

Feel sorry for overheated EU, but here it is cold enough to make me wear jacket at night, now 17 degrees + wind. Amazing summer, love it in Dublin

Daily 327th day streak

Exactly same pattern as was yesterday, just a bit different problem semantics. Definitely worth of recalling the patterns, as they are used in the interviews.

https://leetcode.com/problems/find-a-safe-walk-through-a-grid/description/?envType=daily-question&envId=2026-07-02

#daily #medium #pattern

this is one of bunch of interesting things that are used in my current project in a very tricky manner, by ex-googlers.

I now have exactly same vibe/feeling as I had at my first company (2018, small 60 people outsource company), where I had techlead with 10+ years of experience, with already rejected Amazon and Microsoft offers: everything looks unknown and/or complicated, you overloading your brain with a lot of stuff that you are supposed to know. Understanding that people around are quite fluent in in it comparing to you hurts even more.

Daily 328th day streak

Pretty complicated for me. But uses well known patterns.

https://leetcode.com/problems/network-recovery-pathways/description/?envType=daily-question&envId=2026-07-03

#daily #hard #pattern

Keep this channel a bit educational as well, so what is Network namespace and veth? Why bother?

Why bother -> personally had a bug during one of my projects related to it, and have to make knowledge session to the team about that project, so I have to understand how it works, and how to do oncall, besides that this is how docker and kubernetes work.

By default in you operating system you have host network namespace, some physical device that can receive ethernet frames.

But when you create docker container, or kubernetes pod - under hood it creates separate network namespace, with it's own veth pair that connects it to host namespace, with its own netfilter hooks that can run ebpf, etc.

This is one of the reasons why you run 2 different docker compose files, and they cannot access services of each other (unless on common defined network). Or your docker compose service cannot access some container that was run by "docker run" (default bridge).

Let's consider docker example. Here you can see what happens when ContainerA listens to 5000 port, forwarded as 6000 port and there is incoming request.

First terminology:

Network namespace - is an isolated container of network features/stack including routing table, devices, interfaces, netfilter hooks, etc.

Device aka veth aka virtual ethernet aka endpoint aka network interface - is the physical/virtual container that MAC address and optionally IP address

Bridge - a device that acts as a virtual L2 (Layer 2) switch. Other devices are enslaved to it; it forwards frames between them by destination MACs

So, when you run default container (docker run, NOT docker compose) docker creates separate netns for it, veth pair (2 virtual devices that work like pipe between container netns and host netns), and enslave host's veth endpoint to docker bridge device (virtual switch).

#network #systemdesign

Now incoming request goes to real physical eth0, then through host netns netfilter hooks it gets routed to docker0 bridge device, that device knows it should forward it to vethA (one leg of veth pair) that in turns pipes it into containerA netns to the socket listener.

On the diagram vethA and vethB on the host netns are "enslaved" to docker0 bridge device (virtual switch)

- why netns is needed? it serves isolation purposes. Now with docker compose it adds also dns, so you can access services inside docker compose by name rather than ip + you have full isolation so service in docker-compose1 cannot access service in docker-compose2. Same works for 2 separate pods running in the same machine (they don't get isolation, but they have independent network stack so localhost in pod1 != localhost in pod2)

- why docker0 bridge? cause this gives "gateway" for the containers so that they can talk with each other via this gateway. Without bridge we will have to create mesh between all the containers (many to many)

- why docker DNAT? Because we have exposed port, and without this DNAT the frame can't really go to containerA as the ip would be "host ip" not "docker ip" and there is nothing in host that listens to that port (5000).

- how packet knows after DNAT to 172.17.0.x:5000 that it should go to docker0 device? docker0 gets assigned ip CIDR 172.17.0.0/16 so all the ips in that range are getting routed to it via FIB (Forwarding Information Base which is just table with cidr and handling device) by kernel

- can I create single veth endpoint? -> no, you can create pair of it, as it is like pipe, should have both ends running, otherwise it does not make sense.