DEV Community: Caique Santos

Big O Notation explained

Caique Santos — Wed, 22 Apr 2026 00:14:32 +0000

Introduction

Big O notation measures how fast your code runs as the number of inputs grows.
It’s really important to understand the following algorithms and try to apply the most performatic ones in your solutions. I will order them from fastest to slowest:

O(1) — Constant Time

When using O(1), it doesn’t matter the size of your input, the code will always take the same time to run.

var users = new Dictionary<int, string> {
    { 1, "Caique" },
    { 2, "Maria" },
    { 3, "Fernanda" },
};
var user = users[1];

In this example, it doesn’t matter the size of the collection, accessing a dictionary by key is constant.

O(log n) — Logarithmic Time

Always divides the problem in half at each step. The most common example is a binary search.

int BinarySearch(int[] array, int target) {
    int left = 0;
    int right = array.Length - 1;

    while (left <= right) {
        int mid = (left + right) / 2;

        if (array[mid] == target)
            return mid;

        if (array[mid] < target)
            left = mid + 1;
        else
            right = mid - 1;
    }
    return -1;
}

This one is very efficient when your data is ordered.

O(n) — Linear Time

In linear time, the execution time grows in the exact same proportion as the input length.

var users = new List<string> { "Caique", "Maria", "Fernanda" };

foreach (var user in users) {
    Console.WriteLine(user); 
}

In the example above, if the input length grows by 10%, the execution time grows the same.

O(n log n) — Linearithmic Time

Used in most common sorting algorithms.

var numbers = new List<int> { 5, 2, 8, 1, 3 };

numbers.Sort();

In the example above, the code is performing a merge sort. This complexity is also seen in algorithms like quicksort.

O(n²) — Quadratic Time

This is the main villain in many codebases. The execution time grows very fast as the input length increases.

var users = new List<string> { "Caique", "Maria", "Fernanda" };

foreach (var user1 in users) {
    foreach (var user2 in users) {
        Console.WriteLine($"{user1} - {user2}"); 
    }
}

It’s usually caused by a loop inside another loop. Always try to avoid doing something like that.

Conclusion

If you code, it doesn’t matter if it’s frontend or backend, it’s great to know these algorithms to prevent or diagnose performance issues in your program.

Little's Law: Understanding how much your system can handle

Caique Santos — Thu, 16 Apr 2026 23:15:23 +0000

Introduction

Little's Law is a simple formula that connects the number of items in the system, arrival rate, and average time. Its used when you need to know how many items per time your system can handle.

The Formula

The formula is really simple:

𝐿 = 𝜆 𝑊

L is the average number of items
λ is the entry rate
W is the average time an items spends in the system

In summary: quantity = rate × time.
Let's bring it to real world example common to us — an API. Suppose you have an API with the following metrics:

It gets 10 requests per second.
Each request takes 2 seconds to be completed.

So, in order to know how many requests are in the system at the same time, I apply the Little's Law formula: L = 10 * 2.
As a result, I get 20. So it's safe to assume that my API handles 20 simultaneous requests.

Conclusion

Applying this formula helps you understand your system's capacity, including latency and throughput. With these insights, you can make better decisions about scaling, introducing queues, or setting timeouts.

.NET Interview questions: Key concepts explained

Caique Santos — Thu, 16 Apr 2026 22:40:20 +0000

What's the difference between IQueryable, IEnumerable and List?

IQueryable represents a query that is not executed yet. It allows building the query step by step and is typically executed when iterated.
IEnumerable represents a sequence of data that is already in memory (or will be pulled into memory). It supports iteration and can use lazy execution
List is a concrete collection in memory that implements IEnumerable. It is fully materialized and allows modification (add, remove, etc).

How does the lifecycle work for services in Dependency Injection (Singleton, Scoped, and Transient)?

Singleton creates a single instance for the entire lifetime of the application. The same instance is shared across all requests (e.g., cache service).
Scoped creates one instance per request. The same instance is shared across all components within that request (e.g., DbContext).
Transient creates a new instance every time it is requested. It is commonly used for lightweight, stateless services (e.g., mappers).

What is the difference between FirstOrDefault() and SingleOrDefault()?

FirstOrDefault returns the first element that match the condition, or the default value for that type.
Every type has a default value. Here are some examples:
- classes returns null
- Int returns 0
- bool returns false
SingleOrDefault is very similar to FirstOrDefault, but it throws an exception if the result of the condition returns more than one element.

What is the difference between Value Types and Reference Types?

Value Types
- Store the value directly
- Typically allocated on the stack (but can be stored on the heap in some cases)
- struct, int, bool are examples
- When you copy it, you copy the entire value, like below:

int n1 = 10;
int n2 = a;
n2 = 20; // change does not reflects in "n1"
Console.WriteLine(n1); // 10
Console.WriteLine(n2); // 20

Reference Types
- Store a reference (memory address) to the object
- Typically allocated on the heap
- class, string, array, object are examples
- When you copy it, you copy the reference, not the actual object, like below:

class Person{
    public string Name;
}
var p1 = new Person { Name = "Caique" };
var p2 = p1;
p2.Name = "John"; // change reflects in variable "p1"
Console.WriteLine(p1.Name); // "John"

When to use Record, Struct or Class

Class: Use it when your object has behavior, meaningful functions, and has identity like an entity.

public class User {
    public Guid Id { get; set; }
    public string Name { get; set; }
    public void ChangeName(string name) {
        Name = name;
    }
}

Struct: Use it when you want immutability or you have few properties, like a coordinate object.

public struct Point {
    public int X { get; set; }
    public int Y { get; set; }
}

Record: Use it when you want to compare values, or when you are modeling just data, not behavior, like a DTO.

public record UserDto{
    public required string FirstName { get; init; }
    public required string LastName { get; init; }
};  // or
public record UserDto(string FirstName , string LastName );

REST vs GraphQL vs gRPC Which one should you use?

Caique Santos — Tue, 14 Apr 2026 20:17:29 +0000

Introduction

Over the years, web communication protocols have evolved significantly. There was a time when SOAP dominated, then REST emerged — and it came to stay. Later, GraphQL and gRPC appeared and quickly gained adoption.

Today, REST, GraphQL, and gRPC share the spotlight.

So the question is: when should you use each one?

REST

REST is still the standard choice today. If you're unsure which approach to take, start with REST.

It works best when your API:

will be public
is a simple CRUD
needs to be easy to implement
needs to be widely compatible

This is an example of a typical REST request:

POST /api/customers

Content-Type: application/json

{
  "email": "john@domain.com",
  "name": "John Doe"
}

gRPC

gRPC is a high-performance communication protocol that sends data in a compact binary format instead of JSON.

You should consider gRPC when:

communication happens between microservices
low latency is critical
you need strict contracts (strong typing)
performance is a top priority

Instead of using URLs and HTTP verbs like REST, gRPC uses typed methods:

Service: CustomerService
Method: CreateCustomer

GraphQL

GraphQL is the most flexible option. It allows clients to request exactly the data they need.

Use GraphQL when:

your data has many relationships
you want to avoid multiple requests
the frontend needs to choose exactly what data it gets
you want to avoid fetching too much or too little data

Here is an example of a GraphQL query:

query {
  product {
    name
    price
  }
}

Conclusion

It's great to have multiple protocols to choose from, each one solving problems that the others don’t.

I hope this post helps you decide which protocol to use the next time you're designing a system.

Preventing duplicate requests with Idempotency

Caique Santos — Tue, 14 Apr 2026 00:52:46 +0000

Introduction

Idempotency is a way to ensure that an operation is not executed multiple times with unintended side effects.

Consider this scenario: a client submits an order in your application, but due to a network issue, a double-click on the submit button, or even a malicious attempt to exploit your system, the same request is sent multiple times to your API. How should you handle this?

This is where idempotency comes into play. Below I'll show some strategies used to handle it.

Handling Idempotency in Frontend

There are a few strategies you can apply on the frontend to prevent duplicate requests from being sent, but the frontend alone is not enough to guarantee idempotency. Here are those strategies:

Disable the button immediately after the request is sent to the backend
Redirect the user to a success page after the request is completed
Generate an idempotency key and send it to the backend for proper handling

Handling Idempotency in Backend

To properly handle this issue on the backend, a clean and effective approach is to use middleware to intercept incoming requests and validate the idempotency key provided by the client. Below is an example in C#:

public class IdempotencyMiddleware {
    private readonly RequestDelegate _next;

    public IdempotencyMiddleware(RequestDelegate next) {
        _next = next;
    }

    public async Task Invoke(HttpContext context) {
        var key = context.Request.Headers["Idempotency-Key"].FirstOrDefault();

        if (string.IsNullOrEmpty(key)) {
            await _next(context);
            return;
        }

        // CODE BLOCK TO VERIFY THE IDEMPOTENCY

        await _next(context);
    }
}

However, there are scenarios where an idempotency key provided by the frontend cannot be fully trusted. In such cases, the backend should generate or derive its own idempotency key to ensure consistency and reliability.

Handling Idempotency in Database

You can also enforce idempotency at the database level. Imagine a scenario where you have a form for creating a user. If your database is properly designed with the correct unique constraints, the same user cannot be stored more than once. For example:

CREATE TABLE users (
    id SERIAL PRIMARY KEY,
    email TEXT UNIQUE,
    name TEXT,
    ...
);

In this example, the email field is defined as unique, so even if the system attempts to insert the same user multiple times, the database will prevent duplicates.

Conclusion

In summary, idempotency is essential to prevent duplicate operations and ensure system reliability. Whether handled on the frontend, backend, or database level, combining these approaches leads to a more robust and resilient application.

How Load Balancers distribute traffic

Caique Santos — Sun, 12 Apr 2026 20:30:17 +0000

Introduction

A load balancer acts as an entry point for incoming requests, distributing traffic across multiple instances of an application, to ensure scalability, availability, and reliability.

There are a few types of load balancers:

Static: Uses fixed rules and does not consider the current state of servers
Dynamic: Uses real-time information about servers, such as CPU and memory usage
Stateful: Maintains the state of connections between clients and servers
Stateless: Does not maintain any connection state

Load balancers uses several well-known strategies to effectively distribute traffic. The most relevant ones are:

Round Robin

Round robin distributes incoming requests equally among the servers, without considering their current load.

Weighted Round Robin

Similar to round robin, requests are distributed in order, but server weights are now considered.

Ip Hash

Requests are distributed based on the client's IP address.

URL Hash

The requests are distributed according to its URL.

Least Connections

As its name suggests, it distributes traffic based on the lowest number of active connections among the servers.

Least Response Time

It is very similar to Least Connection strategy. It measures the response time of each server and uses this information to route requests.

Conclusion

Load balancing has proven to be a powerful approach to handling increasing traffic in modern applications. With all the different strategies available, it allows systems to scale while maintaining performance and reliability.

How to properly write a Clean Code

Caique Santos — Wed, 08 Apr 2026 23:58:14 +0000

Introduction

Clean Code is a concept popularized by the book of the same name, written by Robert C. Martin. The main ideia of the book is that a clean code can be read and enhanced by a developer other than its original author. The pillars of this concept are the following below:

Clear naming:

Instead of using:
var x = GetData();
Prefer:
var userEmails = GetUserEmails();

Functions responsability

A function should be as short as possible, and do only one thing.
Avoid:
ProcessUserDataAndSendEmai(user);
Instead, prefer:
ProcessUserData(user);
SendEmail(user);

Low coupling

Avoid tight coupling by instantiating dependencies directly:
private EmailService _emailService = new EmailService();
Prefer depending on abstractions:
private IEmailService _emailService;

Self-explanatory code

Comments can be helpful, but code should be clear on its own.
Avoid:
// increase processed items count count++;
Prefer:
processedItemsCount++;

Consistency

You should stick to a standard. Avoid mixing different naming conventions:
var itensCount= 5; var discount_amount= 0.2;
Use the same pattern:
var itensCount= 5; var discountAmount= 0.2;

Overview

Good code is code that anyone can understand quickly.
You should be able to come back to it years later and still understand it.
It should also be easy to change.

SOLID Principles you won't forget again

Caique Santos — Wed, 08 Apr 2026 23:24:56 +0000

Introduction

SOLID is a set of design principles for writing clean, maintainable, and scalable code. It stands for:

S- Single Responsibility Principle (SRP)

A class or function should have only one responsibility. In the bad example below, the CreateUser function should not handle email-related logic.

Bad example:

public class UserService {
    public void CreateUser(string email) {

        var user = new User(email); 
        _repository.Save(user);

        var smtpClient = new SmtpClient("smtp.company.com"); 
        var message = new MailMessage(                       
            "no-reply@myapp.com", email,"Welcome!",          
            "Your account was created successfully."         
        );                                                   
       smtpClient.Send(message);                           
    }
}

Good example:

public class UserService{
     public void CreateUser(string email) {

        var user = new User(email); 
        _repository.Save(user);

        _emailService.SendWelcome(email);
    }
}

O — Open/Closed Principle (OCP)

Code should be open for extension but closed for modification. This means you should be able to add new behavior without changing existing code. In the bad example below, whenever a new discount is added, you edit the function.

Bad example:

public class DiscountService {
    public double Calculate(string type) {
        if (type == "VIP") return 0.2;            
        if (type == "Regular") return 0.1;
        if (type == "Employee") return 0.3;

        return 0;
    }
}

Good example:

public interface IDiscount {
    double Calculate();
}
public class VipDiscount : IDiscount{ 
    public double Calculate() => 0.2;
}
public class RegularDiscount : IDiscount {
    public double Calculate() => 0.1;
}

public class DiscountService {
    public double Calculate(IDiscount discount) {
        return discount.Calculate();
    }
}

L- Liskov Substitution Principle (LSP)

Subtypes must be replaceable for their base types without breaking the system. This means you should be able to use a subclass anywhere the base class is expected, without causing issues. In the bad example below, the subclass breaks the expected behavior by throwing an exception.

Bad example:

public class Bird {
    public virtual void Fly() { }
}

public class Penguin : Bird {
    public override void Fly() {
        throw new Exception("Penguins can't fly");
    }
}

Bird bird = new Penguin();
bird.Fly();                      // throws exception

Good example:

public abstract class Bird { }

public interface IFlyingBird {
    void Fly();
}

public class Eagle : Bird, IFlyingBird {
    public void Fly() { }
}

public class Penguin : Bird { }

I- Interface Segregation Principle (ISP)

Clients should not depend on methods they do not use. The example below looks like the one from LSP, but the difference here it's about dependency minimization, and the other one is about behavioral contracts.

Bad example:

public interface IWorker
{
    void Work();
    void Eat();
}

public class Robot : IWorker
{
    public void Work() { }

    public void Eat()
    {
        //forced to implement this method even though it doesn't use it
    }
}

Good example:

public interface IWorkable {
    void Work();
}

public interface IEatable {
    void Eat();
}

public class Human : IWorkable, IEatable {
    public void Work() { }
    public void Eat() { }
}

public class Robot : IWorkable {
    public void Work() { }
}

D- Dependency Inversion Principle (DIP)

High-level modules should not depend on low-level modules. Both should depend on abstractions. In other words, don’t depend on concrete implementations — depend on abstractions.

Bad example:

public class UserService
{
    private EmailService _emailService = new EmailService();

    public void CreateUser(string email)
    {
        // logic
        _emailService.Send(email);
    }
}

Good example:

public interface IEmailService{
    void Send(string email);
}
public class EmailService : IEmailService{
    public void Send(string email) { }
}
public class UserService{
    private readonly IEmailService _emailService;

    public UserService(IEmailService emailService) {
        _emailService = emailService;
    }

    public void CreateUser(string email) {
        _emailService.Send(email);
    }
}