DEV Community: Jose Maria Iriarte

Performance Engineering: What Is the System Waiting For?

Jose Maria Iriarte — Fri, 28 Aug 2026 17:09:38 +0000

When a request takes five seconds, the obvious question is what to make faster. The more useful question is what, precisely, the system spent those five seconds doing, or waiting to do. The answer may lie in unnecessary database work, excessive data movement, an execution plan, contention, or the costs of concurrency - and different causes require fundamentally different interventions. Performance engineering begins not with optimization, but with establishing causality: understanding what the system is doing before deciding what it should do differently.

A request takes five seconds to completed. The database query looks suspicious. The endpoint contains an Include(). The response contains considerably more data than the client appears to need. Somewhere in the service layer there is a loop that makes repeated calls. The application is running asynchronously, but under sufficient concurrency the server begins to queue requests and occasionally time out.

There is no shortage of things that could be optimized.

That is precisely the problem.

Performance engineering becomes difficult not when a system has no apparent inefficiencies, but when it has too many.

A slow request can be the visible consequence of several independent mechanisms: inefficient data access, excessive data movement, contention, blocking, serialization, network latency, or resource exhaustion.

Improving one of them may have little effect on the request - or may simply expose another bottleneck further down the chain.

The first task, therefore, is not optimization. It is diagnosis.

Latency Alone Says Very Little

Suppose an API endpoint takes 4.8 seconds.

That number is useful, but only as a starting point.

It does not tell us whether the database consumed 4.7 seconds or 40 milliseconds. It does not tell us whether the application was computing, waiting for a lock, waiting for another service, or waiting for an available thread. It does not tell us whether the database processed millions of rows to return a handful of records

Two requests can have identical latency while having completely different causes.

Consider two simplified cases.

In the first, SQL Server spends several seconds performing a large scan, executing expensive joins, and retrieving rows that the application subsequently discards.

In the second, SQL Server executes the same query in a few milliseconds, but the request spends several seconds waiting for a lock held by another transaction.

From the perspective of the API consumer:

The endpoint is slow.

From the perspective of the engineer:

These are entirely different problems.

The first calls for investigation of query shape, indexes, filtering, projections, and execution plans.

The second may require understanding transactions, locking behavior, concurrent workload, and the session responsible for blocking.

Optimizing the query in the second scenario could accomplish almost nothing.

This distinction is one of the reasons performance engineering cannot be reduced to a collection of ORM tricks or database tuning recipes.

Begin with the Shape of the Work

A useful way to approach performance problems is to ask a deceptively simple question:

What work is the system actually doing?

Consider a seemingly innocent EF Core operation:

var projects = await context.Projects
    .ToListAsync();

The query itself may be perfectly valid. The problem is what happens afterward.

Perhaps the application filters the projects in memory.
Perhaps it maps every entity into a large DTO.
Perhaps it accesses related entities and triggers additional queries.
Perhaps it serializes fields that the client never requested.
Perhaps the endpoint eventually returns hundreds of thousands of rows.

The database may not be the fundamental problem. The system may simply be doing far more work than the request requires.

This is why projection, filtering, and pagination are not merely code-style preferences. They are mechanisms for controlling the quantity of work performed by the system.

The earlier unnecessary work can be eliminated, the less work every subsequent stage needs to perform.

A row that is never selected does not need to be materialized.
An entity that is never modified does not necessarily need to be tracked.
A column that is never returned does not need to be transferred.
A related collection that is never displayed does not need to be loaded.
And data that has already been computed and remains sufficiently stable may not need to be computed again at all.

Performance optimization is often less about making operations faster than about preventing unnecessary operations from occurring in the first place.

The ORM can Conceal the Database

This becomes particularly important when working with an ORM.
LINQ is expressive enough that relatively small pieces of application code can represent surprisingly complicated SQL.

[HttpGet("nplus1-nested")]
public async Task<ActionResult> GetProjectsWithProposals_NestedNPlus1()
{
    var projects = await _context.Projects.ToListAsync();
    var result = new List<object>();

    foreach (var project in projects)
    {
        // Query per project
        var proposals = await _context.Proposals
            .Where(p => p.ProjectId == project.Id)
            .ToListAsync();

        var proposalDtos = new List<object>();

        foreach (var proposal in proposals)
        {
            // Query per proposal - multiplying the problem
            var freelancer = await _context.Users
                .FirstOrDefaultAsync(u => u.Id == proposal.FreelancerUserId);

            proposalDtos.Add(new
            {
                ProposalId = proposal.Id,
                Bid = proposal.Bid,
                FreelancerName = freelancer?.KnownAs
            });
        }

        result.Add(new
        {
            ProjectId = project.Id,
            Proposals = proposalDtos
        });
    }

    return Ok(result);
}

The endpoint above is deliberately simple. It retrieves the projects, then retrieves the proposals for each project, then retrieves the freelancer for each proposal.

Imagine a dataset containing 500 projects and 10 proposals per project. Under the assumptions of this example, the endpoint would perform approximately:

1 + 500 + 5,000 = 5,501 queries.

The code may remain readable and the application may even appear perfectly responsive with ten records. But the problem emerges as the cardinality increases.

This is one of the recurring patterns in performance engineering: an implementation can be locally reasonable and globally pathological.

In this particular example, the solution is not necessarily to make each of those queries faster. It is to change the shape of the operation.

[HttpGet("projects-with-proposals")]
public async Task<ActionResult> GetProjectsWithProposals()
{
    var result = await _context.Projects
        .Select(p => new
        {
            p.Id,
            Proposals = p.Proposals.Select(pr => new
            {
                pr.Id,
                pr.Bid,
                FreelancerName = pr.Freelancer.KnownAs
            }).ToList()
        })
        .ToListAsync();

    return Ok(result);
}

Here the relationships are expressed as part of a single projection.

Rather than loading complete entities and navigating between them procedurally, the query describes the data the endpoint actually needs.

The remedy in cases like this is often projection, appropriate joins or grouping, or carefully chosen batched loading. But even here, the first apparent solution can introduce another problem.

Eliminating thousands of round trips is a substantial improvement. But it leaves us with another question:

How much data are we asking that single query to retrieve?

Bad:
1 Project Query → 500 Proposal Queries → 5,000 Freelancer Queries

Better:
1 Projection Query → Project + Proposals + Freelancer Name

The objective is therefore not:

Make the number of SQL queries as small as possible.

The objective is:

Make the overall data access strategy appropriate for the workload.

That distinction matters.

One query can still be too much. Eliminating thousands of round trips is a significant improvement. But reducing the number of queries does not, by itself, make a data access strategy efficient.

We can replace thousands of small operations with a single operation that retrieves far more information than the request actually requires.

To make the downstream cost visible in a small test dataset, the example below deliberately amplifies several fields and collections. The amplification is artificial; the underlying pattern is not.

[HttpGet("over-fetching")]
public async Task<IActionResult> OverFetching()
{
    var data = await _context.Projects
        .Include(p => p.Client)
        .Include(p => p.Freelancer)
        .Include(p => p.Conversations)
        .AsNoTracking()
        .ToListAsync();

    return Ok(data.Select(p => new
    {
        p.Id,
        p.Title,
        Client = p.Client == null ? null : new
        {
            p.Client.Id,
            p.Client.KnownAs,
            p.Client.FirstName,
            p.Client.LastName,
            p.Client.Bio,
            p.Client.Website,
            p.Client.LinkedIn,
            p.Client.GitHub,
            // Deliberately amplified to make the payload cost visible
            BioCopies = Enumerable.Repeat(p.Client.Bio, 500).ToList()
        },
        Freelancer = p.Freelancer == null ? null : new
        {
            p.Freelancer.Id,
            p.Freelancer.KnownAs,
            p.Freelancer.Bio,
            BioCopies = Enumerable.Repeat(p.Freelancer.Bio, 500).ToList()
        },
        Proposals = Enumerable.Range(0, 50)
            .SelectMany(_ => p.Proposals)
            .ToList(),
        Conversations = p.Conversations.Select(c => new
        {
            c.Id,
            Messages = Enumerable.Range(0, 500)
                .SelectMany(_ => c.Messages)
                .Select(m => new
                {
                    m.Id,
                    m.Content
                })
                .ToList()
        })
    }));
}

The repeated biographies, proposals, and messages are there to make the cost visible in a small dataset. The underlying pattern, however, is quite ordinary.

The endpoint loads complete related entities and entire collections before constructing its response. Only afterward does it decide what information to expose.

That distinction matters.

Data does not become free simply because it arrived in a single query.

Every unnecessary piece of data has consequences beyond the database. It may become an object that EF Core has to materialize, memory that the application has to retain, work that the serializer has to perform, bytes that have to cross the network, and data that the client has to process.
A database optimization that reduces query count while dramatically increasing the amount of data transferred can therefore move the cost rather than eliminate it.

The more fundamental solution is to establish the required data shape before materialization. Filter what is unnecessary, project only the required fields, and paginate collections that do not need to be loaded in their entirety.

In other words, don't ask the database for an object graph and then decide what you need. Whenever practical, ask the database only for what you need, first.

Read the Execution Plan, not Just the LINQ

At this point, we have encountered two very different forms of inefficiency. One produced thousands of database round trips. The other produced a single operation carrying an excessive amount of data. Neither problem can be diagnosed reliably by looking only at how elegant the LINQ appears.

When database work is genuinely contributing to latency, we need to see what the database is actually doing. The database's execution strategy is what matters.

An actual execution plan can reveal behavior invisible at the application layer:

index seeks versus scans
expensive key lookups
inefficient join strategies
filters being applied later than expected
large quantities of data being read to produce a small result
operators responsible for disproportionate execution cost

A query can therefore look perfectly reasonable in C# and still ask SQL Server to do an unreasonable amount of work.

This is why generated SQL and execution plans are indispensable when investigating database performance.

The ORM tells us what we asked the database to do.
The execution plan tells us how the database chose to do it.

Those are not the same thing.

But execution plans have limits

An execution plan is an excellent description of how a query executes. It is not necessarily a description of why a request is slow.

A query can be efficient and still spend most of its lifetime waiting.
Suppose the execution plan looks healthy.

The query uses an appropriate index, returns a small number of rows, and consumes very little CPU.

Yet the endpoint still occasionally takes several seconds.

At this point, continuing to optimize the query may be a category error.
The missing information may exist outside the query itself.

SQL Server could be waiting on a lock.
Another session could be holding a transaction open.
The same query could be executing thousands of times across concurrent requests.
A parameter-sensitive workload could be causing different parameter values to experience radically different execution behavior.
Or the database could be perfectly healthy while the application is exhausting its available resources elsewhere.

This is where workload-level instrumentation becomes important.
From the query to the workload

Tools such as SQL Server Extended Events allow us to observe database activity over time rather than examining a single query in isolation.

That temporal dimension changes the investigation.

Instead of asking:

Why did this query take five seconds?

Ask:

What was happening in the database during those five seconds?

Duration becomes one signal among several.

Logical reads tell us how much data was processed, CPU time helps distinguish computation from waiting, row counts provide clues about over-fetching and inefficient access, session identifiers can help establish relationships between activity, query hashes can reveal repeated execution patterns, wait behavior can indicate contention rather than computational expense.

Consider a particularly revealing combination:

high duration + low CPU + relatively modest reads.

That should make us suspicious: The query may not be expensive at all. It may simply be waiting.

And a query that is waiting for another transaction cannot be made meaningfully faster by shaving a few milliseconds from its execution plan.

The bottleneck exists somewhere else in the system.

The same principle applies above the database

The database is only one stage in the request pipeline.

Imagine that a query is optimized from 800 ms to 80 ms. But the endpoint retrieves a large object graph, maps thousands of entities, serializes an oversized JSON response, and transfers it across a relatively high-latency connection.

The database optimization may be real while the user-visible improvement remains disappointing.

The system has simply moved its center of gravity.

This is why performance investigation needs to follow the request across boundaries:

Database work
Application computation
Object mapping
Serialization
Network transfer
Client-side processing

Each stage can amplify the cost of the previous one.

An unnecessarily large result set is not merely a database problem. It creates more objects. More objects create more allocations. More allocations create more garbage collection pressure. More data requires more serialization. More serialization consumes CPU. More serialized bytes require more network bandwidth. More bytes require more client-side processing.

A seemingly small decision at the database layer can therefore propagate through the entire request pipeline.

Reducing data is often more powerful than optimizing its processing

The preceding examples point toward a broader principle.

Performance problems often become easier to solve when we reduce the quantity of work rather than attempting to accelerate the work itself.

Projection reduces columns.
Filtering reduces rows.
Pagination reduces result sets.
DTO shaping reduces object graphs.
Caching eliminates repeated work.
Aggregation reduces network round trips.
Batching reduces repetitive database interaction.

These techniques look unrelated when presented as isolated recommendations. Conceptually, however, they are variations of the same strategy: Reduce unnecessary work and unnecessary movement.

When Parallelism is the Right Tool

Parallel execution is not inherently a performance problem. In the right circumstances, it is one of the most effective ways to reduce elapsed time.

The strongest candidates are workloads in which the operations are genuinely independent, contain enough useful work to amortize the cost of parallelization, and have sufficient computational or I/O capacity available to execute concurrently.

For example, imagine an application that needs to process a large collection of independent documents, perform CPU-intensive transformations on each one, and combine the results afterward. There is little value in forcing one document to wait for another when the operations have no dependency between them.

The same principle applies to independent I/O operations. If several remote requests can proceed concurrently, waiting for each one sequentially can unnecessarily extend the critical path.

This is where constructs such as Task.WhenAll can be valuable:

var results = await Task.WhenAll(
    GetCustomerAsync(),
    GetPortfolioAsync(),
    GetMarketDataAsync()
);

The operations can make progress concurrently rather than forcing the second operation to wait for the first, and the third to wait for the second.

But concurrency is not free.

The fact that operations can execute concurrently does not mean that they should execute without limit. The useful question is not simply whether work can be parallelized, but whether the system has enough available resources, and enough useful work, to make parallel execution worthwhile.

That distinction becomes clearer in a small benchmark.

When Parallelism Makes Things Worse

A system can sometimes do more work in parallel and become slower rather than faster.

Parallelism has a cost. Work must be partitioned, scheduled, synchronized, and eventually recombined. If the amount of useful work is not sufficient to offset those costs, introducing parallel execution can make the operation slower rather than faster.

I built a deliberately simple BenchmarkDotNet experiment to make that tradeoff visible.

Both implementations retrieve the same 5,000 projects asynchronously from SQL Server. They then perform the same CPU-bound operation on every project. The only difference is how that processing is performed: sequentially in one case, and through Parallel.ForEach in the other.

[Benchmark]
public async Task<int> SequentialProcessing()
{
    var projects = await _context.Projects
        .AsNoTracking()
        .Take(5000)
        .ToListAsync();

    int total = 0;
    foreach (var project in projects)
    {
        total += SimulateWork(project.Title);
    }
    return total;
}

[Benchmark]
public async Task<int> ParallelProcessing()
{
    var projects = await _context.Projects
        .AsNoTracking()
        .Take(5000)
        .ToListAsync();

    int total = 0;
    Parallel.ForEach(projects, project =>
    {
        Interlocked.Add(
            ref total,
            SimulateWork(project.Title));
    });
    return total;
}

The result was not what a simplistic notion of parallelism might suggest.

| Method               |     Mean | Allocated |
| -------------------- | -------: | --------: |
| SequentialProcessing | 206.5 μs |  31.12 KB |
| ParallelProcessing   | 217.0 μs |  33.96 KB |

On this workload, the parallel implementation was approximately 5% slower than the sequential implementation, while also allocating somewhat more memory.

The important observation is not that Parallel.ForEach is "slow." Nor is the lesson that sequential execution is preferable.

The lesson is that parallelism has economics.

There is a cost associated with introducing concurrency, and that cost has to be amortized by the work being parallelized. Partitioning work, scheduling execution, coordinating workers, and synchronizing shared state all introduce overhead.

If that overhead is greater than the time saved through concurrent execution, parallelism has made the operation less efficient.

This is why performance engineering resists rules such as "parallel is faster." The answer depends on the workload, the cost of the individual operation, the available hardware, and the resources competing for that hardware.

The same principle becomes even more important at the application level.

Increasing concurrency can improve throughput when independent work can genuinely proceed simultaneously. But unbounded concurrency can also exhaust database connection pools, increase contention, overwhelm downstream services, or simply move the bottleneck somewhere else.
More parallelism does not necessarily mean more throughput.
Sometimes it simply means that the bottleneck is reached faster.

The Optimization Hierarchy

After working through these patterns, I find it useful to think about performance investigations as a progression rather than a checklist.

First: Where is the time going?
Then: What work is being performed?
Then: Which of that work is actually necessary?
Then: Is the remaining work being performed efficiently?
And finally: What happens when many requests perform this work concurrently?

That sequence matters.

It is tempting to begin with familiar optimizations: AsNoTracking(), caching, an additional index, Task.WhenAll(), response compression, a larger connection pool, more threads.

Sometimes these are exactly the right interventions.

But applying them before establishing the bottleneck turns optimization into speculation. And speculation is expensive. It consumes engineering time, increases system complexity, and can produce changes that improve a benchmark while making the production system less predictable.

Across the examples in this article, the specific mechanisms are different, but the underlying question is the same.

In the first case, the application performed the same category of database work thousands of times.
In the second, it moved and materialized substantially more data than necessary.
In the third, it introduced parallel execution whose overhead could exceed its benefit.

In each case, the important question was not simply "Can this operation be made faster?"

It was

"What work is the system doing, and is that work justified by the result?"

Performance Engineering is an Exercise in Causality

The deeper lesson is that performance work is fundamentally an exercise in establishing causality.

We observe a symptom, formulate a hypothesis, collect evidence, identify the mechanism producing the symptom, change the mechanism. Then we measure again.

That sounds obvious, but it is surprisingly easy to skip.

A slow endpoint invites a fix.
A high CPU graph invites more CPU.
A slow query invites an index.
A large response invites compression.
A concurrency problem invites more parallelism.

Sometimes the intuition is correct.

But the engineering discipline lies in refusing to confuse correlation with cause.

A performance engineer should be able to look at a five-second request and resist the urge to immediately make something faster.

The more important question is:

What, precisely, is responsible for those five seconds?

Until that question has a defensible answer, optimization has not really begun. It is only intervention. And intervention without diagnosis is often just another form of guesswork.

The code examples in this article were adapted from an original .NET freelancer marketplace application I built from scratch and subsequently simplified to demonstrate the performance issues discussed herein. The original project is available on GitHub, and the original performance optimization code is available in the copilot-sanbox branch:

tigerbluejay / Angular-.Net-Integration-Freelancer-Marketplace-App

.NET 8 API with Angular 17/18 Client - An application for freelancers and their clients to work together

💼 Freelancer Marketplace

A full-stack freelancer marketplace web application built with ASP.NET 8 Web API and Angular 18. Users can register, login, and participate with three distinct roles: Administrator, Client, and Freelancer. Freelancers can create profiles, manage portfolios, browse and apply for projects, and chat with clients in real-time. Clients can post projects, manage proposals, and collaborate with freelancers. Admins can manage users and enforce platform rules.

🚀 Features

✅ User Registration & Login

Secure authentication using JWT tokens

Role-based authorization (Admin / Client / Freelancer)

✅ Freelancer Features

Profile management with editable details

Create, edit, delete portfolio items (title, description, photo) with pagination

Browse projects and filter by required skills (5 distinct skills available)

Submit proposals for projects

View submitted proposals (filter by Approved / Rejected / Pending)

Approved proposals automatically generate active projects and enable real-time chat with clients

Messaging system with unread counters, last message preview, timestamps…

View on GitHub

Building Portfolio Insights: Lessons from an Event‑Driven .NET Microservices Dashboard

Jose Maria Iriarte — Tue, 16 Dec 2025 15:59:02 +0000

Over the past weeks, I’ve been working on Portfolio Insights, a personal finance dashboard built on a microservices architecture using .NET 8, RabbitMQ, gRPC, and Docker. The project is a continuation of my exploration into distributed systems, following an earlier e‑commerce microservices application, but applied to a more analytics‑driven, number‑centric domain.

The goal was not to build a production‑ready finance app, but to design and implement a cohesive, end‑to‑end system that demonstrates how independent services can collaborate through synchronous and asynchronous communication, while still supporting a clean and understandable client experience.

tigerbluejay / Microservices-Infrastructure-Personal-Finance-Dashboard

.NET 8 Application implementing Containerized Microservices Infrastructure and Architecture. The Solution consists of four Microservices (Market Data, Portfolio, Analytics and Notifications) a Message Broker, an API Gateway and a .NET Razor Pages Web Client

📊 Portfolio Insights – Personal Finance Dashboard

This project is a demonstration of a .NET 8 microservices-based personal finance and analytics platform. It builds on the architectural patterns and infrastructure explored in my earlier E-Commerce Microservices project, applying them to a number‑driven, analytics‑focused domain.

The application allows users to manage investment portfolios, retrieve simulated market prices, compute analytics asynchronously, and receive notifications based on computed results. All services are containerized and orchestrated via Docker Compose, showcasing a realistic, end‑to‑end distributed system.

Building this application helped solidify my understanding of:

Event‑driven microservices
gRPC and HTTP communication
CQRS and layered architectures
Message‑based analytics pipelines
Vertical Slice and Clean Architectures
Containerized orchestration with Docker
Implementation of Cross-cutting concerns such as validations, logging, health checks and custom exception handling

🧩 Solution Overview

The solution consists of eight projects, all located at the same directory level:

Market Data Service – Simulated market prices and price…

View on GitHub

The Problem Space

At a high level, Portfolio Insights allows a user to:

Manage an investment portfolio (assets and quantities)
Retrieve simulated market prices
Compute portfolio analytics asynchronously
Receive notifications when analytics are refreshed

Under the hood, each of these responsibilities is handled by a separate microservice, each with its own datastore and lifecycle:

Market Data Service – simulates and publishes market prices
Portfolio Service – owns user portfolios and assets
Analytics Service – computes metrics from portfolio and market events
Notification Service – reacts to analytics results

A YARP API Gateway acts as a single entry point, and a Razor Pages web client consumes the system through HTTP calls routed via the gateway.

Architecture First, Code Second

One of the most important lessons from this project was the value of diagramming the system in advance.

With event‑driven architectures, complexity doesn’t come from individual services—it comes from how they interact. Before writing most of the code, I spent time mapping out:

Which service owns which data
Which interactions are synchronous (gRPC)
Which workflows are asynchronous (RabbitMQ events)
How state changes propagate through the system

This upfront design work paid off, especially once I started building the client application. In an event‑driven system, not every user action results in immediate, synchronous data. The client often triggers a command, waits for asynchronous processing, and then queries a different service for the result.

Understanding those flows early made it much easier to design consistent endpoints and avoid tight coupling between the UI and internal service logic.

Communication Patterns in Practice

Portfolio Insights deliberately mixes communication styles:

gRPC is used where low‑latency, request/response interactions make sense—such as the Portfolio Service requesting current prices from the Market Data Service.

RabbitMQ with MassTransit handles event‑driven workflows—portfolio updates, market price changes, and analytics computations.

For example:

A user adds or updates assets in their portfolio.

The Portfolio Service publishes a PortfolioUpdatedEvent.
The Analytics Service consumes this event, joins it with the latest market prices, and computes metrics.
The Analytics Service publishes an AnalyticsComputedEvent.
The Notification Service reacts and stores user notifications.

The client doesn’t talk to all these services directly. Instead, it triggers the initial command and later queries the Analytics or Notification endpoints when data is ready.

Data Ownership and Technology Choices

Each service owns its own data and uses storage appropriate to its needs:

Portfolio Service uses PostgreSQL with Marten, treating the database as a document store.
Analytics Service uses SQL Server with a layered architecture (API, Application, Domain, Infrastructure).
Market Data and Notification Services use SQLite, Redis, and in‑memory stores where persistence requirements are lighter.

This approach reinforced an important principle: consistency across services matters less than clarity of ownership and intent.

The Client Perspective

From the UI side, this project highlighted how deeply backend architecture influences frontend design.

Because analytics are computed asynchronously, the client must:

Trigger actions that start background workflows
Display previously computed data
Refresh views once downstream services have processed events

Designing the Razor Pages client forced me to think carefully about when data should be requested and which service is responsible for it. This is another area where early architectural diagrams were invaluable.

What I Took Away

Beyond the specific technologies, this project reinforced a few broader lessons:

Event‑driven systems reward clear boundaries and explicit contracts
Diagramming workflows early prevents costly redesigns later
Client applications should reflect the realities of asynchronous systems
Docker Compose is an excellent way to reason about distributed systems as a whole

Portfolio Insights is ultimately a learning and portfolio project, but it represents a meaningful step forward in my understanding of modern .NET microservices, asynchronous communication, and system‑level design.

If you’re exploring similar architectures, my biggest recommendation is simple: design the flows before the code. In event‑driven systems, that clarity makes all the difference.

📺 Watch the application overview here:

Take the Next Step

If this article gave you a clearer picture of how an event-driven microservices architecture comes together in a real-world .NET application, here are a few ways to continue exploring:

📁 Explore the GitHub Repository – Review the full source code to see how the services, message flows, API Gateway, and Razor Pages client fit together. Following the code alongside the architecture diagrams is the best way to reinforce how synchronous and asynchronous communication work in practice.

💡 Share the Architecture – If you know someone learning microservices, messaging, or distributed systems in .NET, share this project with them. It’s often easier to understand these concepts through a concrete, end-to-end example.

🖥 Experiment and Extend – Clone the project and try evolving it. Add new events, introduce additional analytics, or adjust how the client reacts to asynchronous workflows. Small changes are a great way to deepen your understanding of event-driven design.

👍 Star the Repository – If you find the project useful, consider starring the repository. It helps others discover the project and supports continued sharing of practical architecture examples.

Working through projects like this builds intuition that goes beyond individual frameworks—helping you design systems that scale in complexity while remaining understandable.

Integrating an Angular Client with a .NET Web API – A Freelancer Marketplace Application

Jose Maria Iriarte — Wed, 17 Sep 2025 15:16:00 +0000

Building full-stack applications is always an exciting challenge, especially when you want to create something original while sharpening your technical skills. Over the past weeks, I worked on a project that combines Angular 17/18 on the frontend with a .NET 8 Web API on the backend: a Freelancer Marketplace application.

tigerbluejay / Angular-.Net-Integration-Freelancer-Marketplace-App

.NET 8 API with Angular 17/18 Client - An application for freelancers and their clients to work together

💼 Freelancer Marketplace

A full-stack freelancer marketplace web application built with ASP.NET 8 Web API and Angular 18. Users can register, login, and participate with three distinct roles: Administrator, Client, and Freelancer. Freelancers can create profiles, manage portfolios, browse and apply for projects, and chat with clients in real-time. Clients can post projects, manage proposals, and collaborate with freelancers. Admins can manage users and enforce platform rules.

🚀 Features

✅ User Registration & Login

Secure authentication using JWT tokens
Role-based authorization (Admin / Client / Freelancer)

✅ Freelancer Features

Profile management with editable details
Create, edit, delete portfolio items (title, description, photo) with pagination
Browse projects and filter by required skills (5 distinct skills available)
Submit proposals for projects
View submitted proposals (filter by Approved / Rejected / Pending)
Approved proposals automatically generate active projects and enable real-time chat with clients
Messaging system with unread counters, last message preview, timestamps…

View on GitHub

This project was born as both a learning exercise and a way to showcase how to bring together two powerful frameworks. The app integrates authentication, role-based navigation, data persistence, pagination, SignalR for live chat and presence, and various UX touches like modals, guards, and notifications. It is a real-world scenario where clients and freelancers interact on a platform, with administrators keeping the ecosystem in check.

Why a Freelancer Marketplace?

Rather than building a generic CRUD app, I wanted something closer to a real-world product. A freelancer marketplace is perfect because it naturally involves multiple roles, dynamic interactions, and workflows that push both the API and the Angular client beyond the basics.

The application defines three distinct roles:

Freelancer: builds a profile, adds portfolio items, browses projects, submits proposals, and chats with clients when proposals are approved.
Client: creates projects, manages incoming proposals, and collaborates with freelancers.
Admin: oversees the platform with a panel to enable/disable user accounts and monitor online presence in real-time.

Each role has its own dedicated navigation bar and tailored user experience.

Angular Meets .NET

The project began in Angular 17 and was later migrated to Angular 18, making it a good case study for keeping frontend dependencies modern and compatible. On the backend, .NET 8 Web API provides authentication (JWT), persistence with EF Core and SQLite, and real-time capabilities with SignalR.

Some highlights of the integration:

Authentication & Authorization: JWT tokens handled in Angular via interceptors, with client-side guards preventing unauthorized or disabled users from accessing the app.
CRUD + Pagination: Portfolio items, projects, and proposals are paginated for smooth browsing.
SignalR Integration: Real-time chat between freelancers and clients, with unread message counters, presence indicators, and autoscrolling conversations.
User Experience: Angular guards warn against unsaved changes, modals confirm critical actions, and toasters provide feedback.

Lessons Learned

A few insights emerged while building the marketplace:

Folder structure matters: I started with every Angular component in its own folder. While not perfectly organized, it still worked. The project reminded me that iteration and refactoring are natural parts of learning.
Angular and .NET pair well: The synergy between Angular’s reactive front-end design and .NET’s structured API made development smooth. Once authentication and SignalR were configured, everything else clicked together.
Real-world scenarios force depth: Unlike toy projects, building a freelancer marketplace required thinking through workflows: proposals, approvals, active projects, and messaging. This depth made the integration feel authentic.

Why This Matters

If you’re learning full-stack development, there’s tremendous value in picking a project idea that excites you and has practical complexity. You’ll encounter the kind of challenges that surface in professional applications: handling state, ensuring security, designing APIs for multiple roles, and maintaining clarity in the codebase.

This project is more than just a tutorial exercise—it’s a working demonstration of how Angular and .NET can power a modern, role-based platform where real-time collaboration is central.

Closing Thoughts

The Freelancer Marketplace app gave me the chance to practice integration between Angular 17/18 and .NET 8, explore SignalR real-time communication, and think carefully about user roles and workflows.

For anyone building similar projects, I’d recommend starting small but choosing an application idea with enough moving parts to stay engaging. That’s how you grow not only as a developer, but also as a designer of systems that make sense to real people.

📺 Watch the application overview here:

Take the Next Step

If this article helped you understand how Angular can consume a .NET API service in a real-world application, here's how you can continue your journey:

📁 Explore the GitHub Repository – Dive into the repository to examine the Angular app and the API integration. Follow along with the code to reinforce your understanding of consuming and interacting with APIs in .NET.

💡 Share the Knowledge – Know someone who’s learning to work with .NET APIs or Angular? Share this guide with them to help them accelerate their learning and improve their skills.

🖥 Start Coding – The best way to grasp these concepts is by getting hands-on. Take the provided code and experiment with adding new features or integrating other APIs.

👍 Like the Repository – If you find the project helpful, give it a thumbs-up! This will help others discover the repository and benefit from it too.

By engaging with this tutorial and project, you'll build a strong foundation in .NET API, Angular Client integration, ready to implement these skills in real-world applications.

Mental Math Hacks: Swift Estimations of Powers and Roots for Programmers

Jose Maria Iriarte — Sat, 24 May 2025 03:00:00 +0000

In a world overflowing with digital tools, it’s easy to dismiss mental math as outdated — a quaint relic from the pre-calculator age. But there’s something uniquely powerful about sharpening your ability to think numerically without external support. Like optimizing code for runtime efficiency, refining your mental math streamlines your internal thought processes and reduces your cognitive load.

This article is based on a short guide I wrote called Estimating Powers and Roots Fast - Essential Tactics to Speed Up Mental Calculations with Whole Numbers, the third in a three-part series I began in 2018. The project started as a personal challenge: to improve how I processed numbers mentally. I wanted to go beyond fuzzy estimations and reclaim the skill of clear, structured calculation — the kind that feels more like flow than friction.

What began as scattered notes turned into three compact books, each focused on two core operations: addition & subtraction, multiplication & division, powers & roots. This article distills the key strategies from the third of those books.

These are not “tricks” in the superficial sense — they’re practical, reusable mental algorithms. Some are intuitive, others might feel surprising at first, but all are meant to reduce latency between seeing a problem and arriving at a confident answer.

Whether you’re optimizing memory usage or tallying totals in your head, these techniques will train you to think faster, reduce errors, and — yes — enjoy math a little more.

Note that the original guide contains detailed explanations on these and other techniques, impossible to reproduce in an article of this nature or length. If you are serious about incorporating these techniques, I strongly recommend you read the full guide, linked at the end of this article. It's completely free to download and read.

⚙️ Key Strategies for Estimating Powers

🧱 Foundational Powers

Know the small powers of 2–10 by heart. These are your “power landmarks” — quick-access reference points that anchor your estimation.

Example: If you know `5^3 = 125` and `5^4 = 625`,
and you’re asked to estimate `5^3.5`, 
you know it must fall between 125 and 625 — closer to the former.

🔄 Break Down and Multiply

Decompose a base into smaller components whose powers you know, then recombine using multiplication rules.

Example: Estimate `6^4` by computing `(2 × 3)^4 = 2^4 × 3^4 =
16 × 81 = 1296`.

🔍 Beyond Simple Break Down and Multiply

Use substitutions or approximations when clean decomposition isn’t possible — apply the nearest base you can work with.

Example: Estimate 14^6.
Instead of calculating this directly, 
rewrite as (14^2)^3 = 196^3.
Then approximate 196^3 ≈ (200)^3 = 8,000,000.
Since 196 < 200, you know the true result is slightly less 
— maybe around 7.5 million.
This gets you in the right ballpark quickly without full multiplication.

🚀 Elevating Multiples of 10

When a number is a clean multiple of 10, strip the zeroes, calculate the power, then adjust for scale.

Example: `30^2 = (3 × 10)^2 = 3^2 × 10^2 = 9 × 100 = 900`.

🧱 Larger Bases

Use known approximations or reduce the exponent by converting to smaller base expressions.

Example: `20^4 = (2 × 10)^4 = 2^4 × 10^4 =
16 × 10,000 = 160,000`.

⚙️ Key Strategies for Estimating Roots

🟩 Perfect Square Roots

Work backwards from known squares and interpolate if necessary.

Example: Estimate `√1600`. 
You know `40^2 = 1600`, 
so the answer is exactly 40.

🧮 Perfect Square Roots (5+ Digits)

Look at the number of digits and use digit-pattern clues
from common squares to narrow down candidates.

Example: Estimate `√62500`. 
You know `250^2 = 62500`, 
and that squares ending in “500” often come from roots ending in 50.

🧊 Extending to Perfect Cubes (≤ 6 digits)

Use the number of digits to guess the number of digits in the root, then apply unit-digit patterns to narrow it down.

Example: Estimate ∛614125.
Split the number: 614 and 125.
Note that:
80³ = 512,000
90³ = 729,000
Since 614,125 falls between 80³ and 90³, the cube root is in the 80s.
The number ends in 5, and cube roots ending in 5 produce cubes ending in 5.
So the cube root is 85.

📦 Cube Roots of 7–9 Digit Numbers

Group the digits, then use both first and last digits to estimate. You may also need digital sums to break ties.

Example: Estimate ∛478,211,768.
First digits: between 700³ = 343M and 800³ = 512M 
→ So it's in the 700s.
Last digit is 8, which corresponds to a root ending in 2 (since 2³ = 8).
Digital sum of the number is 44 → 4+4 = 8 
→ root's digital sum should be 2, 5 or 8.
Try 722, 752, 782 → Best estimate: 782.

🧮 4th and 5th Roots

Estimate the root by matching number of digits in the base using scientific notation — then refine.

Example: Estimate ∜1×10¹².
You’re looking for the 4th root of a trillion.
100⁴ = 10⁸, 1000⁴ = 10¹² → so ∜(1×10¹²) = 1000.

🧰 Practice & Progress

Like any skill, speed and confidence come with practice. Try:

Estimating shopping discounts, volumes and distances involving roots and powers
Calculating loans, and compound interests
Keeping track of wellness stats for your weigh training for example

The goal isn’t to become a human calculator, but to develop a mental agility that helps in work, school, and everyday thinking.

📘 Download the Full Guide

This article is a condensed version of my guide:

👉 Download the PDF: Estimating Powers and Roots Fast
Estimating Powers and Roots Fast (PDF)

This guide contains much more detailed information about how to profit from the various tactics including various reference powers and roots tables and expanded explanations. If you are serious about these techniques I strongly recommend you read the guide.

🚀 Help Others and Keep the Conversation Going!

If you found this article helpful, here’s how you can contribute to spreading the knowledge:

👍 Like this article to show your support and help others discover it.

📁 Bookmark it so you can easily come back to these techniques anytime you need them.

🔄 Share it with friends or colleagues who might benefit from faster mental math strategies.

💬 Comment below with your favorite tip, a trick you’ve used, or any questions you might have — let’s keep learning together!

By liking, sharing, or commenting, you're not just helping me reach more readers — you're contributing to a community that thrives on growth and knowledge. Sharing this article helps others enhance their mental math skills, reducing cognitive load and boosting productivity. Your engagement could make someone’s day easier or help them see math in a new, empowering way!

Thank you for being part of this learning journey! 🙌

Optimizing Mental Math: Fast Multiplications and Divisions for Software Engineers

Jose Maria Iriarte — Sat, 17 May 2025 03:00:00 +0000

This article is based on a short guide I wrote called Multiplying and Dividing Fast - Essential Tactics to Speed Up Mental Calculations with Whole Numbers, the second in a three-part series I began in 2018. The project started as a personal challenge: to improve how I processed numbers mentally. I wanted to go beyond fuzzy estimations and reclaim the skill of clear, structured calculation — the kind that feels more like flow than friction.

Whether you’re optimizing memory usage or tallying totals in your head, these techniques will train you to think faster, reduce errors, and — yes — enjoy math a little more.

📃 Core Multiplication Tactics

🔄 Doubling

Use for multiplying by 2, 4, 8, etc. (powers of two).

Example: 
354 × 2 = 708

🔄 Doubling Twice or Thrice

Used for ×4, ×8, ×16, etc.

Example: 
42 × 16 = 672
84, 168, 336, 672

🔄 Multiples of 10

Multiply as if zeroes weren’t there, then append them.

Example: 
40 × 45,000 = 1,800,000

💵 Multiplying by 5 (Halving)

Multiply by 10, then divide by 2.

Example: 
5 × 74 = 370
740 / 2 = 370

🔢 Squares Ending in 5

Multiply tens digit by (n+1) and append 25.

Example: 
95 × 95 = 9025
9 x 10 = 90

🔑 Multiplying by 11 (2-digit)

Add digits and sandwich between.

Example: 
11 × 72 = 792
7 + 2 = 9
7 9 2

🔑 Multiplying by 11 (3+ digits)

Pairwise addition from right to left, carry included.

Example: 
11 × 3,480 = 38,280

8 + 0 = 8
4 + 8 = 12
3 + 4 = 7

30000
07000
01200
00080
00000

📃 Multiplying by 15

Decompose into (10 + 5) then apply halving.

Example: 
15 × 382 = 5,730

10 x 382 = 3820
3820 / 2 = 1910
3820 + 1910

📈 Two-Digit Products (Lattice-like)

Apply place-value cross multiplication.

Example: 
34 × 65 = 2,210

3 x 6 = 18
4 x 5 = 20
3 x 5 + 4 x 6 = 39

1800
0390
0020

📈 Three-Digit Multiplication

Break into hierarchical place-value multiplications.

Example: 
123 × 432 = 53,136

4 x 1
1 x 3 + 4 x 2 
2 x 1 + 2 x 3 + 3 x 4
3 x 3 + 2 x 2
3 x 2

40000
11000
02000
00130
00006

📈 Two-Digit by Three-Digit

Use the same principle, append 0s where needed.

Example: 
44 × 452 = 19,888

💸 Balancing for Multiplication

Shift factors to easier equivalents.

Example: 
144 × 24 = (288 × 12) = 3,456

(144 x 2) / (24 / 2) =
288 x 12 =
288 x 10 + 288 x 2 =
2880 + 576

🌐 Rounding and Compensation

Round one number to an easier figure, then subtract excess.

Example: 
16 × 191 = (16 × 200) - (16 × 9) = 3,056
3,200 - 144

🔹 Associative Property

Break one factor into primes or easier groups.

Example: 
22 × 267 = 11 × 534 = 5,874

11 x 2 x 267
267 doubled, 534
534 x 11

3 + 4 = 7
5 + 3 = 8

📃 Distributive Property

Use expanded form: a(b + c)

Example: 
51 × 295 = (50 × 295) + 295 = 15,045

📃 Products Near Powers of 10 (One Away)

Use complements to subtract from powers of 10.

Example: 
387 × 999 = 386,613
387000 - 387

📃 Products Near Powers of 10 (Both Close)

Use cross-adjustment and product of differences.

Example: 
997 x 998 = 995,006

997 - 1,000 = -3, 998 - 1000 = -2

997 + (-2) = 995
-3 x (-2) = 6

995000
000006

📃 Core Division Tactics

📃 Division as Inverse Multiplication

Think "what times X gives me Y?"

Example: 
72 ÷ 6 = 12

6 x 12 = 72

🧰 Advanced Halving

Successive halving for dividing by 4, 8, 16, etc.

Example: 
3,760 ÷ 16 = 235

1880, 940, 470, 235

📉 Divisibility Rules (3, 5, 9, 10, etc.)

Use digital sums or ending digits.
Detailed explanations of this family of subtechniques can be found in the ebook linked below.

Example:

495

Digital sum = 4 + 9 + 5= 18
Digital sum = 1 + 8 = 9

Divisible by both 3 and 9

📃 Rounding & Compensation (Division)

Round dividend/divisor then adjust the result.

Example: 
684 ÷ 3 = (690 - 6) ÷ 3 = 228
230 - 2

📈 Balancing in Division

Shift dividend/divisor by a common factor.

Example: 
77 ÷ 11 = (770 ÷ 110) = 7

🔹 Associative in Division

Break divisor into friendly parts.

Example: 
264 ÷ 12 = (264 ÷ 3) ÷ 4 = 22

📃 Distributive in Division

Break up dividend to divide in parts.

Example: 
(840 + 60) ÷ 30 = 28 + 2 = 30

🧰 Practice & Progress

Like any skill, speed and confidence come with practice. Try:

Estimating bills or invoices in your head
Practicing products while walking
Playing games that push number recognition and recall

The goal isn’t to become a human calculator, but to develop a mental agility that helps in work, school, and everyday thinking.

📘 Download the Full Guide

This article is a condensed version of my guide:

👉 Download the PDF: Multiplying and Dividing Fast
Multiplying and Dividing Fast (PDF)

This guide contains much more detailed information about how to profit from the various tactics including various reference multiplication and division tables and expanded explanations, in particular, for the sections regarding divisibility rules. If you are serious about these techniques I strongly recommend you read the guide.

🚀 Help Others and Keep the Conversation Going!

If you found this article helpful, here’s how you can contribute to spreading the knowledge:

👍 Like this article to show your support and help others discover it.

📁 Bookmark it so you can easily come back to these techniques anytime you need them.

🔄 Share it with friends or colleagues who might benefit from faster mental math strategies.

💬 Comment below with your favorite tip, a trick you’ve used, or any questions you might have — let’s keep learning together!

Thank you for being part of this learning journey! 🙌

Low-Latency Mental Math: Quick Additions and Subtractions for Software Developers

Jose Maria Iriarte — Sat, 10 May 2025 03:00:00 +0000

This article is based on a short guide I wrote called Adding and Subtracting Fast - Essential Tactics to Speed Up Mental Calculations with Whole Numbers, the first in a three-part series I began in 2018. The project started as a personal challenge: to improve how I processed numbers mentally. I wanted to go beyond fuzzy estimations and reclaim the skill of clear, structured calculation — the kind that feels more like flow than friction.

Whether you’re optimizing memory usage or tallying totals in your head, these techniques will train you to think faster, reduce errors, and — yes — enjoy math a little more.

📚 Foundational Concepts

🔢 Number Complements

Master pairs that sum to 10, 20, and 100. These are essential for fast subtraction and pattern recognition.

Examples:
3 + 7 = 10  
6 + 14 = 20  
87 + 13 = 100

✌️ Table of 2 and Its Uses

Doubling is powerful for grouping and estimating.

Example:
4 + 2 = 3 × 2

➕ Rule of Adding to 9

Add 10 instead, then subtract 1.

Example:
9 + 7 = 10 + 7 = 17 → 17 - 1 = 16

➕ Rule of Adding to 8

Same logic, subtract 2 instead of 1.

Example:
8 + 5 = 10 + 5 = 15 → 15 - 2 = 13

🧮 Core Addition Techniques

🧩 Decomposing

Break numbers apart to make things easier.

Example:
5 + 7 = 5 + (5 + 2) = 10 + 2 = 12

👀 Scanning

Before adding, scan the numbers for potential carrying.

Example:
123 + 231 + 245  
Check units, then tens, then hundreds

📐 Aligning

Align digits by place value in your head.

Example:
684 + 941 + 198  
Add hundreds: 600 + 900 + 100 = 1600  
Add tens: 80 + 40 + 90 = 210  
Add ones: 4 + 1 + 8 = 13  
Total = 1600 + 210 + 13 = 1823

🧮 Rounding and Compensation

Round one term to a nearby 10 or 100, then adjust.

Example:
39 + 48 = 40 + 48 = 88 → 88 - 1 = 87

⚖️ Balancing

Round two numbers in opposite directions to cancel out adjustments.

Example:
97 + 59 + 31  
Round 59 → 60 (+1)  
Round 31 → 30 (−1)  
Net effect: 97 + 60 + 30 = 187

👯 Grouping (Sequential)

Combine easy-to-add groups to reduce mental load.

Example:
13 + 17 + 58 + 12  
→ 10 + 20 + 60 + 10 = 100  
→ Remaining: 3 + 7 + 8 + 2 = 20  
Total = 100 + 20 = 120

➖ Core Subtraction Techniques

🔄 Reverse and Negate

Flip subtraction when the subtrahend is larger.

Example:
2 - 8 = -(8 - 2) = -6

🎯 Subtracting from Multiples of 10

Use complements to subtract from 10, 100, or 1000.

Example:
100 - 47 = 53  
Think: (10 - 4 - 1 in tens) + (10 - 7 in ones)

🔁 Addition Techniques for Subtraction

Many addition tricks (decomposing, rounding) work in reverse.

Example:
84 - 47 = (84 - 44) - 3 = 40 - 3 = 37

🧲 Matching

Add the same number to both terms to simplify.

Example:
37 - 22 → add 3 to both → 40 - 25 = 15

🔀 Mixed Operations

When you mix additions and subtractions, group all negatives and positives separately, then combine.

Example:
83 - 45 - 15 - 38  
= 83 - (45 + 15 + 38)  
= 83 - 98 = -(98 - 83) = -15

🎯 Practice & Progress

Like any skill, speed and confidence come with practice. Try:

Estimating grocery bills in your head
Practicing sums and differences while walking
Making a game out of spotting friendly numbers in daily life

The goal isn’t to become a human calculator, but to develop a mental agility that helps in work, school, and everyday thinking.

📘 Download the Full Guide

This article is a condensed version of my short guide:

👉 Download the PDF: Adding and Subtracting Fast
Adding and Subtracting Fast (PDF)

🚀 Help Others and Keep the Conversation Going!

If you found this article helpful, here’s how you can contribute to spreading the knowledge:

👍 Like this article to show your support and help others discover it.

📑 Bookmark it so you can easily come back to these techniques anytime you need them.

🔄 Share it with friends or colleagues who might benefit from faster mental math strategies.

💬 Comment below with your favorite tip, a trick you’ve used, or any questions you might have — let’s keep learning together!

Thank you for being part of this learning journey! 🙌

Lessons from Building a One-Man Startup

Jose Maria Iriarte — Sat, 03 May 2025 09:26:15 +0000

Over the course of several years, I embarked on an ambitious solo journey to create a digital education business. What began as a simple idea evolved through multiple iterations—each one teaching me something about technology, process, and the nature of entrepreneurship itself. This is the story of that journey—from Katacoding to Sigmacasts to Octal Stream—and the insights I gained along the way.

The Evolution: From Video Calls to Scalable Content

The concept began with Katacoding, a platform offering live, one-on-one online coding lessons via video calls. While the model had promise, it lacked scalability. That realization led to Sigmacasts, a curated series of educational videos on math and computer science. The production process taught me how to craft educational narratives and use video to communicate abstract ideas.

Eventually, these two concepts merged into Octal Stream—a platform offering on-demand, instructor-led video lessons focused on foundational web development. Octal Stream aimed to deliver the human quality of live lessons with the reach and polish of asynchronous video.

Technologies I Leveraged (and Learned)

The project became an opportunity to develop and integrate a wide range of technologies and tools. Among them:

AWS Cloud Services: Lightsail virtual machines, S3 object storage, Route 53 for DNS, and Simple Email Service for transactional and marketing communication.

WordPress: Using the Avada theme along with essential plugins like Memberpress for subscriptions, Stripe Payments, Yoast SEO, and Wordfence.

External services: Vectera for video hosting, iPage for WordPress hosting, and stock image libraries for visual content.

Creative tools: KdenLive for video editing, GIMP for image creation and manipulation, and Office/LibreOffice for scriptwriting, presentations, and animations.

Code and browser-based work: Sublime Text for scripting and site customizations, regular browser-based demonstrations for teaching content.

Each technology had a learning curve, but it also brought a deeper understanding of full-stack development, infrastructure management, and the production workflow behind digital products.

Protocols and Systems I Built

To stay productive and consistent, I developed internal protocols and workflows for nearly every aspect of the business:

Audio and video recording standards: Detailed specs and consistent steps to ensure production quality.

Content pipeline: A structured system for writing, recording, editing, and publishing video lessons.

Deployment and migration guides: Documentation to help with website migrations and service updates.

Marketing systems: Templates and notes for SEO, ad copywriting, social media strategy, and campaign tracking.

These internal systems gave structure to a complex creative and technical process. They also laid the groundwork for future delegation, should I ever grow the team.

Business Infrastructure and Exploration

Beyond technology, I explored what it meant to create a business infrastructure designed to support international growth. This included:

Incorporating a Delaware LLC with IncNow
Filing for an EIN (Employer Identification Number) with the IRS
Opening a Mercury Bank account for international payments
Securing a U.S.-based virtual business address and registering it with the U.S. Embassy in Buenos Aires
Investigating options like Stripe Atlas for potential U.S. incorporation, bank account and market reach

These steps broadened my understanding of global business logistics and helped me think about scalability from both a financial and legal standpoint.

What I Learned About Organizations

Working solo gave me an intimate look at what it means to be the organization. I wore every hat—developer, designer, instructor, marketer, sysadmin, and CEO. That experience was humbling and illuminating.

Some key realizations:

Organizations are ecosystems. Each function—product, marketing, operations, finance—demands time and energy. Trying to scale all of them equally at once is a recipe for burnout.

Focus is survival. Passion projects are energizing, but if they don’t support revenue, they should be postponed until the essentials are working.

Efficiency matters. Free and open-source tools can dramatically reduce startup costs, though finding and configuring them is becoming more complex.

Competing for attention is expensive. I learned to be cautious with paid ads and SEM—especially when going up against established corporations with large budgets.

Lessons I’ll Take Into Future Ventures

Looking back, I see this experience not as a failed startup, but as a highly concentrated entrepreneurial education. Here’s what I’ll carry forward:

Validate early. I built a product before building an audience. Future efforts will prioritize community and conversation early on.

Don’t over-invest in polish before traction. From branding to video production, perfection can wait until the core model is validated.

Embrace “good enough” tools. I spent time building infrastructure that others had already optimized. Next time, I’ll stand on the shoulders of giants.

Specialize, then expand. Wearing many hats taught me versatility—but deep progress came when I narrowed my focus.

Align effort with value. I now ask: “Is this task critical to delivering value to users or generating revenue?” If not, it gets deferred.

Closing Thoughts

This journey taught me more than any book or course could have. I now have a blueprint for launching future products more strategically, with clarity on what matters most in early-stage entrepreneurship.

Building Octal Stream may not have made me a millionaire, but it did make me a better technologist, thinker, and builder. And next time, I’ll start not from zero—but from here... and hopefully, you will have drawn some valuable lessons too from my experience if you decide to embark on a similary journey!

Foundations of Data Structures and Algorithms in C#

Jose Maria Iriarte — Sat, 12 Apr 2025 18:30:09 +0000

CSharp-DataStructures-Algorithms-Fundamentals is a focused, foundational repository written in C# that helps developers understand and implement the most essential data structures and algorithms through simple, self-contained examples.

It was developed as a response to the scarcity of educational DSA content in C#, particularly when compared to the abundance of materials available in JavaScript, Python, or Java. This project mirrors the pedagogical structure of popular repositories in those languages, with a particular focus on readability and conceptual clarity rather than optimality or cleverness.

What's Inside

This repository covers a range of fundamental topics in data structures and algorithms, including:

Arrays: Basic operations and manipulation techniques.
Linked Lists: Implementation and traversal methods.
Stacks and Queues: Understanding LIFO and FIFO structures.
Trees: Binary trees, traversal algorithms, and more.
Graphs: Representation and traversal techniques.
Recursion: Solving problems through recursive approaches.
Sorting Algorithms: Implementations of Bubble Sort, Insertion Sort, Merge Sort, Quick Sort, and more.
Searching Algorithms: Linear and Binary Search methods.
Hash Tables: Understanding hashing and collision resolution.
Frequency Counters: Techniques for counting occurrences efficiently.
Sliding Window: Optimizing problems involving subsets of data.
Divide and Conquer: Breaking problems into subproblems for efficient solutions.
Greedy Algorithms: Making optimal choices at each step.
Dynamic Programming: Solving complex problems by breaking them down into simpler subproblems.
Graph Algorithms: Including Dijkstra's algorithm for shortest paths.

Each topic is presented with clear, concise examples to aid understanding.

Motivation and Purpose

The repository was created to address two key issues:

The lack of beginner-friendly C# materials on DSA

While countless tutorials and repositories exist for languages like JavaScript or Python, comparable resources in C# are rare. This project adapts proven learning structures to C#, offering a consistent and readable path through classic problems.
To promote conceptual understanding over clever implementations

Rather than diving into complex or optimal code, the examples here emphasize digestibility — making it easier for learners to grasp the logic behind each structure or algorithm before worrying about performance tuning.

Target Audience

Developers with little or no formal education in data structures and algorithms
Bootcamp or self-taught programmers transitioning to more technical interviews
C# developers seeking a clean, minimal reference for foundational concepts
Interviewees needing a conceptual refresher on common DSA patterns in C#
Mentors and educators looking for teachable, idiomatic examples

Selected Examples

The repository includes a variety of topics such as pointers, recursion, sorting, searching, and graph traversal. Below are three representative samples.

1. Count Unique Values (Multiple Pointers Pattern)

namespace CSharp_DataStructures_Algorithms_Fundamentals
{
    using System;

    public static partial class MultiplePointers
    {
        public static int CountUniqueValues(int[] arr)
        {
            if (arr.Length == 0) return 0;

            // Pointer for tracking unique values
            int i = 0;

            for (int j = 1; j < arr.Length; j++)
            {
                // When two pointers point to different elements
                if (arr[i] != arr[j])
                {
                    i++; // Increment the pointer for unique values
                    arr[i] = arr[j]; // Assign current value to next unique slot
                }
            }

            return i + 1; // Total unique values
        }
    }
}

Use Case: Counts the number of unique values in a sorted array.
Concepts Reinforced: Two-pointer technique, array traversal, in-place updates.

2. QuickSort (Divide and Conquer)

public static void QuickSort(int[] arr, int left, int right)
{
    if (left < right)
    {
        // Find the pivot index
        int pivotIndex = Pivot(arr, left, right);

        // Sort left and right halves
        QuickSort(arr, left, pivotIndex - 1);
        QuickSort(arr, pivotIndex + 1, right);
    }
}

// Example breakdown:
// QuickSort([4,6,9,1,2,5,3])
// Pivot = 4 → partitions array
// [3,2,1,4,6,9,5] → 4 is now in place
// Recurse on each side
/*
QuickSort(arr, left=0, right=6)  
  Pivot: 4, PivotIndex: 3  
  Array: { 3, 2, 1, 4, 9, 5, 6 }

  ├── QuickSort(arr, left=0, right=2)  
  │     Pivot: 3, PivotIndex: 2  
  │     Array: { 1, 2, 3, 4, 9, 5, 6 }  
  │  
  │     ├── QuickSort(arr, left=0, right=1)  
  │     │     Pivot: 1, PivotIndex: 0  
  │     │     Array: { 1, 2, 3, 4, 9, 5, 6 }  
  │     │     ├── QuickSort(arr, left=0, right=-1) → Return  
  │     │     └── QuickSort(arr, left=1, right=1) → Return  
  │  
  │     └── QuickSort(arr, left=3, right=2) → Return  
  │  
  └── QuickSort(arr, left=4, right=6)  
        Pivot: 9, PivotIndex: 6  
        Array: { 1, 2, 3, 4, 6, 5, 9 }  
        ├── QuickSort(arr, left=4, right=5)  
        │     Pivot: 6, PivotIndex: 5  
        │     Array: { 1, 2, 3, 4, 5, 6, 9 }  
        │     ├── QuickSort(arr, left=4, right=4) → Return  
        │     └── QuickSort(arr, left=6, right=5) → Return  
        └── QuickSort(arr, left=7, right=6) → Return
*/

Use Case: In-place sorting of arrays via partitioning.
Concepts Reinforced: Recursion, divide-and-conquer strategy, pivot logic.

3. Dijkstra’s Algorithm (Graph Traversal with Priority Queue)

public List<string> Dijkstra(string start, string finish)
{
    var nodes = new PriorityQueue<string>();
    var distances = new Dictionary<string, int>();
    var previous = new Dictionary<string, string?>();
    var path = new List<string>();

    foreach (var vertex in adjacencyList.Keys)
    {
        if (vertex == start)
        {
            distances[vertex] = 0;
            nodes.Enqueue(vertex, 0);
        }
        else
        {
            distances[vertex] = int.MaxValue;
            nodes.Enqueue(vertex, int.MaxValue);
        }
        previous[vertex] = null;
    }

    while (nodes.Count > 0)
    {
        var dequeuedNode = nodes.Dequeue();
        var smallest = dequeuedNode.Item1;

        if (smallest == finish)
        {
            while (previous[smallest] != null)
            {
                path.Add(smallest);
                smallest = previous[smallest];
            }
            break;
        }

        if (distances[smallest] != int.MaxValue)
        {
            foreach (var edge in adjacencyList[smallest])
            {
                int candidate = distances[smallest] + edge.Weight;
                if (candidate < distances[edge.Node])
                {
                    distances[edge.Node] = candidate;
                    previous[edge.Node] = smallest;
                    nodes.Enqueue(edge.Node, candidate);
                }
            }
        }
    }

    path.Add(start);
    path.Reverse();
    return path;
}
// Example: Dijkstra("A", "F")
// Shortest path: A → C → D → F
// Total cost: 5

/*
Initialization:
A distance = 0, other nodes = ∞
Priority queue: [A(0), B(∞), C(∞), D(∞), E(∞), F(∞)]

Step 1: Process A
A → B (4), A → C (2)
B updated to 4, C updated to 2
Priority queue: [C(2), B(4), D(∞), E(∞), F(∞)]

Step 2: Process C
C → D (2 + 2 = 4)
D updated to 4
Priority queue: [D(4), B(4), E(∞), F(∞)]

Step 3: Process B
B → E (4 + 3 = 7)
E updated to 7
Priority queue: [D(4), E(7), F(∞)]

Step 4: Process D
D → E (4 + 3 = 7) (no change)
D → F (4 + 1 = 5)
F updated to 5
Priority queue: [F(5), E(7)]

Step 5: Process F
F is the target, stop.

Path Reconstruction:
F → D → C → A
Reverse: A → C → D → F
Final Output
["A", "C", "D", "F"]
This is the shortest path from A to F, with a total cost of 5.
*/

Use Case: Computes the shortest path between two nodes in a weighted graph.
Concepts Reinforced: Graph traversal, priority queues, dictionaries, and path reconstruction.

Project Philosophy

This repository serves as a bridge between learning and implementation — it doesn’t aim to provide complete academic coverage of each topic, but instead prioritizes conceptual clarity and accessible code.

Each algorithm is written with readability in mind. More advanced topics such as recursion or graph traversal are broken down with commentary and examples, ensuring learners not only see the implementation but also understand the underlying mechanics.

Explore the Repository

If this collection supports your own study or helps you mentor others, consider:

⭐ Starring the GitHub repo

💾 Bookmarking or saving this article

🧑‍🤝‍🧑 Sharing it with peers or mentees on a similar path

Your support helps reinforce the need for clean, foundational content in C# — especially in an ecosystem where such resources are hard to come by.

View the full collection here:

tigerbluejay / CSharp-DataStructures-Algorithms-Fundamentals

Clean C# implementations of fundamental data structures and algorithms for technical interviews and foundational understanding. Covers arrays, linked lists, trees, graphs, recursion, sorting, searching, dynamic programming, tries, and more—well-organized and ideal for .NET developers.

C# Data Structures and Algorithms Fundamentals

This repository is a comprehensive repository of essential data structures and algorithms implemented in C#, with clean, well-documented code and clear organization. This project demonstrates proficiency in core programming concepts such as arrays, linked lists, stacks, queues, trees, graphs, recursion, sorting, and searching algorithms. Ideal for technical interviews and foundational understanding, it reflects a strong grasp of algorithmic thinking and software engineering principles using .NET technologies.

01 - Frequency Counters

The Frequency Counter pattern uses objects or hash tables to count occurrences of values, enabling efficient comparisons and data validations. It is particularly useful in problems involving anagram detection, duplicates, and value matching across arrays or strings. This folder introduces foundational logic used in optimizing nested loops and improving time complexity.

02 - Multiple Pointers

The Multiple Pointers strategy involves creating pointers or indices that move toward each other or in parallel to solve…

View on GitHub

A Curated Repository of Early C# Algorithms for Technical Interviews

Jose Maria Iriarte — Sat, 12 Apr 2025 09:40:46 +0000

Collection of Basic C# Algorithms is a focused, practical repository designed to assist developers — particularly junior and mid-level professionals — in preparing for technical interviews that involve algorithmic problem-solving in C#.

This collection emerged from personal experience and professional necessity. It serves as a foundational resource for those who may not have received formal training in data structures and algorithms, yet frequently encounter algorithmic challenges during interviews for roles that do not require algorithmic problem-solving as part of day-to-day responsibilities.

These are not optimal solutions, but solutions optimized for beginners who may find it easy to think in simpler, yet more verbose terms.

Motivation and Purpose

The motivation behind this repository was twofold:

To reduce signal noise: Developers preparing for interviews often face an overwhelming volume of information, with algorithm repositories offering hundreds of problems of varying relevance or complexity. This project aims to distill the essentials — the most frequently asked, straightforward algorithmic questions — and present them clearly in C#.
To support self-taught developers: Many developers come to the field through nontraditional paths. This repository provides them with an accessible point of entry into algorithmic thinking, aligned with industry expectations.

Target Audience

Junior to mid-level developers preparing for interviews
Developers transitioning into more technical or algorithm-heavy roles
Individuals without a computer science background seeking structured, minimal examples of classic problems
Interviewees applying to companies that require a basic proficiency in algorithms without expecting advanced computer science knowledge

Selected Examples

Below are three representative algorithms from the repository. Each example demonstrates core algorithmic reasoning and is implemented in clear, idiomatic C#.

1. Reverse Words in a String

public static void ReverseWordsinaString()
{
    string input = "Hello World";

    string[] words = input.Split(' ');

    Array.Reverse(words);

    string reversedString = string.Join(" ", words);

    Console.WriteLine(reversedString);
}

Use Case: Reverses the order of words in a given string (e.g., "hello world" becomes "world hello").
Concepts Reinforced: String splitting, array manipulation, and use of Array.Reverse.

2. Check if a String is a Palindrome

public static void IsStringPalindrome()
{
    string input = "racecar";

    input = input.Replace(" ", "").ToLower();

    string reversed = ReverseString(input);

    bool isPalindrome = input.Equals(reversed);

    if (isPalindrome)
    {
        Console.WriteLine("The string is a palindrome.");
    }
    else
    {
        Console.WriteLine("The string is not a palindrome.");
    }
}

// Helper method to reverse a string
static string ReverseString(string s)
{
    char[] charArray = s.ToCharArray();
    Array.Reverse(charArray);
    return new string(charArray);
}

Use Case: Checks whether a string reads the same forwards and backwards.
Concepts Reinforced: String normalization, helper methods, conditionals.

3. Checking for Prime Numbers

public static void IsIntPrime()
{
    int number = 17; // Replace with the positive integer you want to check
    bool isPrime = IsPrime(number);

    if (isPrime)
    {
        Console.WriteLine($"{number} is a prime number.");
    }
    else
    {
        Console.WriteLine($"{number} is not a prime number.");
    }
}

static bool IsPrime(int n)
{
    if (n <= 1)
    {
        return false;
    }
    if (n <= 3)
    {
        return true;
    }
    if (n % 2 == 0 || n % 3 == 0)
    {
        return false;
    }

    for (int i = 5; i * i <= n; i += 6)
    {
        if (n % i == 0 || n % (i + 2) == 0)
        {
            return false;
        }
    }

    return true;
}

Use Case: Determines if int is a prime number
Concepts Reinforced: Nested loops and condition checking. General Math.

Project Philosophy

This project was developed as a precursor to more formal study in data structures and algorithms. It reflects both practical interview experience and a desire to support developers at transitional points in their careers. Each algorithm is designed to be immediately understandable and directly relevant to common screening questions.

Rather than aiming for academic completeness, this collection prioritizes relevance, clarity, and working solutions. The implementation style is intentionally straightforward, prioritizing readability and accessibility over optimization or cleverness.

Explore the Repository

If you find the repository helpful in your own preparation or mentoring, consider:

Starring the repo on GitHub
Bookmarking or liking this article for future reference
Sharing it with colleagues or students navigating similar challenges

Your support helps signal that there’s value in concise, beginner-friendly technical resources.

You can view the full collection here:

tigerbluejay / CollectionofBasicCSharpAlgorithms

Common Basic Algorithms used in interviews related to C# positions - A collection of fundamental algorithms implemented in C#, covering sorting, searching, and data structure manipulation. This repository helps strengthen algorithmic thinking and coding efficiency in C#.

CollectionofBasicCSharpAlgorithms

Collection of Basic C# Algorithms is a curated repository featuring fundamental algorithm implementations written in C#. It serves as a practical reference for developers seeking to understand core algorithmic concepts through concise, well-organized examples. Covering a range of topics from sorting and searching to string manipulation, this collection is ideal for beginners looking to strengthen their problem-solving skills or for experienced programmers needing quick access to foundational C# algorithm patterns.

View on GitHub

Starting as a Junior Developer and Breaking into the Job Market – A Retrospective

Jose Maria Iriarte — Wed, 09 Apr 2025 01:52:23 +0000

Back in 2020, I recorded these two podcast episodes as part of a now-archived project. They cover my early experiences as a Junior Developer and my journey breaking into the job market back in 2014. A decade later, I’m sharing them here in case they resonate with anyone starting out or reflecting on their own path.

Hope you enjoy!

📺 Listen to the first episode here:

📺 Listen to the second episode here:

Share Your Story

If these episodes strike a chord, feel free to:

💾 Bookmark them for later
🎧 Share with someone starting out in tech
💬 Drop a comment with your own early career memories

Every shared experience helps make the path a little clearer for those just beginning.

Mastering CSS Video Series: A Structured, Concise Blueprint for Essential Modern CSS

Jose Maria Iriarte — Sat, 05 Apr 2025 20:15:14 +0000

CSS is the backbone of web design, yet many tutorials are either too complex or too superficial. This article introduces a free, 24-video CSS series designed for beginners, developers in need of a refresher, and experienced coders exploring hidden features. Covering everything from fundamental syntax, selectors and properties to advanced topics like animations, transformations, and modern CSS features, each concise, practical lesson (3-9 minutes) ensures you gain a strong, structured understanding without feeling overwhelmed. Watch the first video or explore the full playlist to start learning today! 🚀

🔥 Why a Thorough Introduction to CSS Matters

CSS is the foundation of the web design—every webpage you visit utilizes it. Whether you're a complete beginner or a developer looking to strengthen your fundamentals, a solid grasp of CSS is essential for designing harmonious, beautiful, pages that leave an impression.

⚡ The Challenge

Many CSS courses are long, bloated, or overly complex, making it hard to stay engaged. Some tutorials focus on theory without real-world application, while others rush through key concepts without proper explanations.

🎯 The Solution

I’ve created a free, 24-video CSS series that breaks everything down into short, focused lessons (3-9 minutes each). It’s beginner-friendly, to the point, and packed with practical examples—perfect for learning CSS quickly without feeling overwhelmed. The code provided is tested to work perfectly, so upon completing each lesson, you may view the styles in any web browser.

🚀 What’s in This Video Series?

The series begins with an introduction to styles, selectors and basic CSS principles. Starting from sylesheet references, the course moves quickly through CSS Reset, and common styles such as Fonts, Borders, Margins, Padding, and Sizing. From there, the course explores image and hyperlink-related Styles emphasizing core principles that guide how styles are prioritized as well as the rules behind how they “cascade”.

In the second half, the course dives into often-overlooked advanced features, such as linear and radial gradients, transforms, transitions and animations. A dedicated section breaks down tables in detail, introducing key notions and best practices. These final lessons focus on modern CSS features —concepts rarely covered in quick-start guides but essential for mastering cascading stylesheets.

🔍 Who Is This For?

Whether you're a beginner looking for a quick but solid foundation, a developer in need of a CSS refresher, or an experienced coder curious about hidden features you might have overlooked in a rushed introduction years ago, this series has something for you. Each video is designed to be concise yet insightful, covering both core concepts and lesser-known elements to help you write cleaner, more beautiful CSS and understand thoroughly why sometimes CSS styles appear to behave so unpredictably.

🎬 How to Get Started?

Getting started is simple! Just hit play on the first video below, which introduces you to the fundamentals of CSS:
📺 Watch the first video here:

To follow along with the full 24-video series, check out the complete playlist:
👉 Watch the full playlist here: CSS Video Series

Each video is short, focused, and beginner-friendly, so you can learn at your own pace. If you find the series helpful, consider subscribing for more content and sharing it with others who might benefit!
Thank you for reading through. I hope you will enjoy this thorough video introduction to CSS.

Support Clean Learning Resources

If this CSS series helps strengthen your skills — or offers clarity where other tutorials fell short — consider:

⭐ Saving or bookmarking the article for future reference
🎬 Sharing it with friends, mentees, or coding communities
🧑‍🤝‍🧑 Spreading the word about clean, structured beginner resources

Your support helps highlight the importance of clear, concise educational content in a field that often feels overwhelming for newcomers.

Mastering HTML Video Series: A Structured, Concise Blueprint for Essential Modern HTML

Jose Maria Iriarte — Sat, 15 Feb 2025 16:26:01 +0000

HTML is the backbone of the web, yet many tutorials are either too complex or too superficial. This article introduces a free, 12-video HTML series designed for beginners, developers in need of a refresher, and experienced coders exploring hidden features. Covering everything from fundamental syntax and semantic elements to advanced topics like ARIA, microformats, and modern HTML features, each concise, practical lesson (3-9 minutes) ensures you gain a strong, structured understanding without feeling overwhelmed. Watch the first video or explore the full playlist to start learning today! 🚀

🔥 Why a Thorough Introduction to HTML Matters

HTML is the foundation of the web—every webpage you visit is built on it. Whether you're a complete beginner or a developer looking to strengthen your fundamentals, a solid grasp of HTML is essential for writing clean, structured, and accessible code.

⚡ The Challenge

Many HTML courses are long, bloated, or overly complex, making it hard to stay engaged. Some tutorials focus on theory without real-world application, while others rush through key concepts without proper explanations.

🎯 The Solution

I’ve created a free, 12-video HTML series that breaks everything down into short, focused lessons (3-9 minutes each). It’s beginner-friendly, to the point, and packed with practical examples—perfect for learning HTML quickly without feeling overwhelmed.

🚀 What’s in This Video Series?

The series begins with an introduction to the basic HTML template, covering fundamental syntax conventions that will guide you throughout the course. It starts with comments, then moves into an overview of the most common HTML tags—first conceptually, then through real-world examples. From there, the course explores specialized elements like "figure", "aside", and "nav", emphasizing the importance of semantic HTML and why each tag matters.

In the second half, the course dives into often-overlooked advanced features, such as ARIA, microformats, and microdata, helping you write accessible and structured code. A dedicated section breaks down forms in detail, introducing key elements and best practices. The final lessons focus on modern HTML features, including newer input types and elements—components rarely covered in quick-start guides but essential for mastering the language.

🔍 Who Is This For?

Whether you're a beginner looking for a quick but solid foundation, a developer in need of an HTML refresher, or an experienced coder curious about hidden features you might have overlooked in a rushed introduction years ago, this series has something for you. Each video is designed to be concise yet insightful, covering both core concepts and lesser-known elements to help you write cleaner, more effective HTML.

🎬 How to Get Started?

Getting started is simple! Just hit play on the first video below, which introduces you to the fundamentals of HTML:
📺 Watch the first video here:

To follow along with the full 12-video series, check out the complete playlist:
👉 Watch the full playlist here: HTML Video Series

Support Structured Learning

If this HTML series helps you grasp the core concepts or dive deeper into advanced features, consider:

⭐ Bookmarking or saving this article for future reference
🎥 Sharing it with fellow learners, colleagues, or students starting their web development journey
🧑‍🤝‍🧑 Spreading the word about accessible, concise tutorials for mastering HTML

Your engagement encourages the creation of more clean, foundational resources that make learning web development easier for everyone.