DEV Community: Abdulhai Mohamed Samy

Concurrency in Go Green Threads VS .NET Kernel-Level Threads

Abdulhai Mohamed Samy — Mon, 03 Nov 2025 11:28:53 +0000

Difficulty: Advanced

Reading Time: 35 min read

Last Updated: November 3, 2025

💡 How do Go and .NET handle concurrency differently — and why does it matter for performance and scalability?

Concurrency is everywhere in modern software, but the underlying mechanisms vary drastically. Go embraces lightweight Goroutines multiplexed onto a few OS threads, while .NET relies on kernel-level threads managed by the CLR Thread Pool. Understanding these approaches isn’t just academic — it shapes how you design, scale, and optimize applications.

Why does it matter?

Concurrency isn’t just about running multiple tasks at once — it’s about managing execution, resources, and data safely across threads or Goroutines. The model you choose affects performance, scalability, and developer effort.

Inside this article, you’ll explore:

Worker Pools

Learn how Go requires manual worker pool setup using Goroutines and channels versus .NET’s automatic thread pool management. Discover the trade-offs between control vs automation.
Data Safety & Shared Resources

Understand Go’s CSP (Communicating Sequential Processes) approach to avoid shared mutable state, compared to .NET’s lock-based shared memory design.
Error Handling and Graceful Shutdown

See how Go uses context. Context and defer/recover to manage worker lifecycles and failures, while .NET relies on try/catch and CancellationTokens.
Scheduling & Coordination

Dive into Go’s minimalist primitives for time-based and event-driven scheduling versus .NET’s rich frameworks like IHostedService, Quartz.NET, and Hangfire.
Performance Characteristics

Compare memory overhead, context switching, and throughput between lightweight Goroutines and kernel threads. Explore scenarios where Go’s M:N model outperforms .NET, and where the CLR Thread Pool shines.
Practical Guidance

Learn when to prefer Go for high-density, I/O-heavy workloads and when .NET is better for managed, enterprise-grade architectures.

Concurrency in Go and .NET is a study in philosophy: Go prioritizes lightweight explicit control, while .NET emphasizes managed orchestration and safety. Both achieve high performance — just through very different routes.

Read the full article in my Notion blog here:

🔗 Read it on Notion

📌 Note:

The full article lives in my Notion blog here, which serves as the single hub for all my articles and ensures consistent formatting across platforms. You can read this article directly in the Notion link above. Feel free to share your thoughts or feedback in the site comments—or drop me a note on LinkedIn.

About the Author

Abdul-Hai Mohamed | Software Engineering Geek’s.

Writes in-depth articles about Software Engineering and Architecture.

Follow on GitHub and LinkedIn.

Parallel Computing

Abdulhai Mohamed Samy — Mon, 03 Nov 2025 11:25:01 +0000

Difficulty: Advanced

Reading Time: 35 min read

Last Updated: November 3, 2025

💡 What truly happens when computers run tasks “in parallel”?

It’s one of those concepts we use daily — but behind the scenes, parallel computing is a deep orchestration of hardware execution units, instruction pipelines, and multi-core scheduling, all designed to make programs feel instantaneous.

From instruction-level parallelism (ILP) inside a single core to data and task parallelism across multiple processors — the way we split, schedule, and synchronize work defines how modern systems achieve scale.

Why does it matter?

Parallelism isn’t just a performance trick — it’s a design philosophy.

Understanding how processors exploit concurrency at every level helps engineers write faster, more scalable code, and design architectures that fully utilize hardware potential.

Inside this article, you’ll explore

The foundational concepts and classifications of parallel computing, from Flynn’s taxonomy to the modern multi-core era.
How task decomposition and workload distribution enable concurrent execution across multiple processing units.
The architectural models that define parallel systems — shared-memory, distributed-memory, and hybrid designs — and their implications for scalability.
The types of parallelism that shape computational performance: data, task, and pipeline parallelism.
The synchronization and communication mechanisms that maintain consistency across concurrent processes.
Understanding parallelism is essential for building modern, high-performance systems that scale efficiently across cores and clusters.

Parallel computing isn’t just about dividing work; it’s about orchestrating simultaneous execution in a way that preserves correctness, maximizes throughput, and adapts to the complexity of modern hardware.

Read the full article in my Notion blog here:

🔗 Read it on Notion

📌 Note:

About the Author

Abdul-Hai Mohamed | Software Engineering Geek’s.

Writes in-depth articles about Software Engineering and Architecture.

Follow on GitHub and LinkedIn.

Write-Optimized Index Structures, Bitmap Indices, and PostgreSQL

Abdulhai Mohamed Samy — Mon, 01 Sep 2025 12:27:17 +0000

Tags: #SnowTech #Databases #Indexing #LSMTrees #BitmapIndex #SpatialIndexing #TemporalIndexing #PostgreSQL

Difficulty: Advanced

Reading Time: 45 min read

Last Updated: September 01, 2025

⚡ Beyond B+-Trees: Write-Optimized Index Structures, Bitmap Indices, and PostgreSQL

Databases live and die by their ability to access data efficiently. For decades, the B+-tree was the unquestioned king of indexing, and hash tables powered countless equality lookups. But the world has changed:

Streaming systems generate millions of inserts per second.
Analytical platforms run queries across terabytes of data.
Spatial & temporal workloads demand multi-dimensional indexing.
And storage hardware itself has evolved, shifting from spinning disks to SSDs and beyond.

👉 In this reality, traditional indexing alone cannot keep up.

This article explores the modern indexing ecosystem—structures and strategies that are no longer “optional,” but fundamental to building scalable, high-performance systems:

Write-Optimized Indexing

Log-Structured Merge (LSM) Trees buffer writes in memory before merging them to disk.
- Core of RocksDB, Cassandra, LevelDB.
- Handles massive insert/update workloads.
Buffer Trees generalize the idea of batching—reducing I/O complexity to near-optimal levels.

Bitmap Indices

Designed for low-cardinality attributes.
Use bit vectors + compression (Roaring, WAH) to allow lightning-fast set operations.
The backbone of data warehouses and OLAP systems.

Spatial & Temporal Indices

R-Trees for spatial queries (GIS, mapping, geometry).
Interval Trees & Hybrids for temporal data (auditing, versioning, time-series).
Enable efficient nearest-neighbor, intersection, and range queries where B+-trees fail.

PostgreSQL’s Index Arsenal

Postgres unifies theory and practice:

B-Tree, Hash → Classic queries.
GiST, SP-GiST → Extensible for unstructured/spatial data.
GIN, BRIN → Full-text search & large sequential datasets.
Advanced features like multicolumn, covering indexes, and index-only scans give developers surgical performance control.

Why this matters

Index design is not an afterthought—it is the foundation of performance engineering. Whether you’re building a real-time system, a warehouse, or a geospatial application, understanding these structures determines if your database scales gracefully or collapses under pressure.

Read the full article in my Notion blog here:

🔗 Read it on Notion

📌 Note:

About the Author

Abdul-Hai Mohamed | Software Engineering Geek’s.

Writes in-depth articles about Software Engineering and architecture.

Follow on GitHub and LinkedIn.

Hash Indices

Abdulhai Mohamed Samy — Mon, 01 Sep 2025 12:20:18 +0000

Difficulty: Advanced

Reading Time: 35 min read

Last Updated: September 01, 2025

Why Hash Indices?

In the last article, we explored Ordered Indexes and the B+-Tree — structures that shine when queries rely on order. They allow efficient range queries like:

“Find all products priced between $100 and $500.”
“List all usernames alphabetically between Alice and Bob.”

But sometimes… order doesn’t matter at all.

If your query is:

“Find the record with ProductID = 30035”
“Does username = 'Alice99' exist?”

…then walking down a multi-level tree is overkill. You don’t need sorted traversal — you just need the answer, instantly.

That’s where Hash Indices come in.

Hashing transforms a search key (e.g., ProductID) into a bucket address using a hash function. Instead of traversing nodes, the DB jumps straight to the location where the record should be.

👉 Ordered Indexes & B+-Trees → best for range queries.

👉 Hash Indices → best for point queries (exact match lookups).

Inside Hash Indexing

Hash Functions → map search keys into buckets.
Collisions → two different keys land in the same bucket. Handled with chaining or open addressing.
Static Hashing → fixed buckets, fast but inflexible.
Dynamic Hashing → buckets split/grow as data expands. (Extendible & Linear Hashing).
Limitations → no ordering → range queries are useless.

Why It Matters

When the query is “find this exact record”, nothing beats hashing.

That’s why high-performance systems — from OLTP databases to key-value stores — rely heavily on hash indices for equality lookups.

Modern systems often combine hashing with Bloom Filters, which act as a quick pre-check for membership. While Bloom Filters may yield false positives, they guarantee no false negatives, making them perfect for filtering massive datasets.

Read the full article in my Notion blog here:

🔗 Read it on Notion

📌 Note:

About the Author

Abdul-Hai Mohamed | Software Engineering Geek’s.

Writes in-depth articles about Software Engineering and architecture.

Follow on GitHub and LinkedIn.

Ordered Indices

Abdulhai Mohamed Samy — Mon, 01 Sep 2025 12:02:34 +0000

Difficulty: Advanced

Reading Time: 35 min read

Last Updated: September 01, 2025

⚡ Ordered Indices vs. B+ Trees — Why Indexing Had to Evolve

In the last article, we explored B-trees and B+ trees—brilliant self-balancing data structures that quietly power most databases. But before we celebrate them as heroes, let’s rewind.

Because in the beginning, databases relied on something simpler: the ordered index.

📖 Ordered Indices — The First Step

Think of an ordered index like a sorted list of records.

Searching is fast: binary search takes you to the right record quickly.
Range queries are effortless: just scan sequentially from one key to the next.

But there’s a catch.

What happens when new records arrive out of order? Or when data gets deleted?

Suddenly, you’re faced with shifting entire rows or relying on overflow blocks (spare storage areas for “out of place” records). This is manageable on small datasets—but at billions of records, it’s a nightmare of slow writes and messy fragmentation.

That’s where ordered indices hit their limit.

🌲 Enter the B+ Tree

The B+ tree took everything good about ordered indices (sorted access, fast range queries) and solved their biggest flaws:

Efficient Updates → No more shifting entire data blocks. Instead, inserts and deletes trigger local splits or merges.
Guaranteed Balance → The tree stays shallow, so searches are always O(log n). Even with millions of rows, only a few I/Os are needed.
Leaf Links → Since leaves are connected, range queries are still blazing fast.

Instead of a fragile, shifting structure, the B+ tree gave databases a self-organizing index that stays efficient under constant growth and churn.

This wasn’t just an improvement—it was the necessary evolution to make indexing viable at scale.

⚙️ Modern Optimizations

B+ trees didn’t stop at their original design. Databases have extended them with smart tricks, including:

Prefix compression → Shrinks string keys to save space.
Bulk loading → Builds an index much faster from sorted data.
Buffer management → Keeps hot nodes in memory, reducing disk I/O.
Cache-aware layouts → Align nodes with CPU cache lines for speed in in-memory DBs.
Storage adaptation → Wide nodes for magnetic disks, merge-friendly writes for SSDs, and hybrid layouts for RAM.

That’s why, decades later, the B+ tree remains the backbone of indexing in MySQL, PostgreSQL, Oracle, and even modern in-memory systems.

Read the full article in my Notion blog here:

🔗 Read it on Notion

📌 Note:

About the Author

Abdul-Hai Mohamed | Software Engineering Geek’s.

Writes in-depth articles about Software Engineering and architecture.

Follow on GitHub and LinkedIn.

B+ Tree

Abdulhai Mohamed Samy — Mon, 01 Sep 2025 11:47:46 +0000

Difficulty: Intermediate

Reading Time: 25 min read

Last Updated: September 01, 2025

🌳 B+ Trees — The Gold Standard of Database Indexing

When you run:

SELECT * FROM Products WHERE price BETWEEN 50 AND 150;

…the difference between that query taking milliseconds or minutes often comes down to one structure: the B+ tree.

Most developers learn about arrays, linked lists, and binary search trees early on. But in the real world of databases and filesystems, these structures fall short. They’re too linear, too shallow, or too memory-focused. Disk access is slow — and disk I/O is the bottleneck every serious database has to solve.

That’s where the B+ tree comes in.

Unlike simple binary search trees, the B+ tree:

Keeps itself perfectly balanced, no matter how many records you insert or delete.
Stores multiple keys per node, aligned with disk block sizes, to minimize expensive I/O.
Places all actual data in the leaf nodes, while internal nodes act only as guides.
Links those leaves together, making range queries blazingly fast with just a single pass.

This design means operations scale logarithmically (O(log n)), even across billions of records. It’s why relational databases like MySQL, PostgreSQL, and SQLite, and filesystems like NTFS, XFS, HFS+, all rely on B+ trees under the hood.

But the brilliance of B+ trees isn’t just in raw performance. It’s in the elegance of the design:

🌲 Binary Search Trees gave us ordering but crumbled under imbalance.
🌲 AVL & Red-Black Trees introduced balance, but only suited for in-memory data.
🌲 B-Trees adapted to disk, but mixed data and routing.
🌲 B+ Trees perfected the model: separating routing from data, linking leaves, and unlocking massive scalability.

So the next time you fire off a query and marvel at how instantly your results appear, remember: it’s a humble B+ tree making it happen, silently keeping the system in balance.

Read the full article in my Notion blog here:

🔗 Read it on Notion

📌 Note:

About the Author

Abdul-Hai Mohamed | Software Engineering Geek’s.

Writes in-depth articles about Software Engineering and architecture.

Follow on GitHub and LinkedIn.

Memory Management Unit (MMU) and Translation Lookaside Buffer (TLB)

Abdulhai Mohamed Samy — Mon, 30 Jun 2025 14:27:19 +0000

Difficulty: Advanced

Reading Time: 11 min read

Last Updated: June 30, 2025

Ever wondered how your computer knows where to find the data you ask for?

Behind every memory access, there’s a hidden translator: the Memory Management Unit (MMU). And to keep things blazing fast, it has a secret helper—the Translation Lookaside Buffer (TLB).

These two are the unsung heroes of computing. Without them:

Virtual memory would be painfully slow.
Context switching would break performance.
Process isolation and security would collapse.

Key insights the article covers:

How the MMU translates virtual to physical memory
Why the TLB cache is critical for speed
What happens on a TLB flush (and why it’s so expensive)
How replacement policies and multi-level TLB hierarchies keep systems efficient
The real-world performance bottlenecks engineers face

When you think about memory management, do you see it as an OS problem, a hardware problem, or a beautiful collaboration between the two?

If you’ve ever hit a page fault, debugged memory issues, or wondered why context switching is costly — this article connects the dots.

Read the full article in my Notion blog here:

🔗 Read it on Notion

📌 Note:

About the Author

Abdul-Hai Mohamed | Software Engineering Geek’s.

Writes in-depth articles about Software Engineering and architecture.

Follow on GitHub and LinkedIn.

io_uring — The Modern Asynchronous I/O Revolution in Linux

Abdulhai Mohamed Samy — Mon, 30 Jun 2025 13:28:28 +0000

Difficulty: Advanced

Reading Time: 10 min read

Last Updated: June 30, 2025

💡 Have you ever wondered why, despite Linux’s reputation for performance, traditional I/O calls often feel slow and blocking?

For decades, the kernel’s I/O model has revolved around syscalls and context switches — a model that worked, but came with real costs in performance and scalability. Enter io_uring, a Linux feature that quietly rewrites the rules of how applications talk to the kernel.

How does it eliminate syscall overhead with shared rings?
Why are databases, web servers, and logging systems racing to adopt it?
And if it’s so powerful, why are Google and Android still hesitant to enable it by default?

In this article, I break down the architecture, the algorithms, and the real-world use cases of io_uring — and why it might be the biggest leap in Linux I/O since epoll.

Read the full article in my Notion blog here:

🔗 Read it on Notion

📌 Note:

About the Author

Abdul-Hai Mohamed | Software Engineering Geek’s.

Writes in-depth articles about Software Engineering and architecture.

Follow on GitHub and LinkedIn.

What Happens When a Computer is Turned On?

Abdulhai Mohamed Samy — Mon, 30 Jun 2025 12:08:57 +0000

Difficulty: Beginner

Reading Time: 5 min read

Last Updated: June 30, 2025

1. What Happens When a Computer is Turned On?

💡 What really happens inside your computer the moment you press the power button?

It’s a process most of us take for granted—but behind the scenes, a fascinating chain of steps turns cold hardware into a living, working system.

From BIOS/UEFI checks and the mysterious POST beeps, to the MBR and bootloader, all the way through to Linux’s init (or systemd) launching daemons and graphical interfaces—this process is the foundation of everything we do in software engineering.

Why does it matter?

Understanding the boot process isn’t just trivia—it’s the backbone of debugging, performance tuning, and even security hardening. Whether you’re a student exploring OS fundamentals or an engineer tackling low-level issues, knowing what happens at boot unlocks a whole new perspective on how systems really work.

Read the full article in my Notion blog here:

🔗 Read it on Notion

📌 Note:

About the Author

Abdul-Hai Mohamed | Software Engineering Geek’s.

Writes in-depth articles about Software Engineering and architecture.

Follow on GitHub and LinkedIn.