Vitor Aleluia

Welcome to My Blog: Engineering, Architecture, and Notes

Tue, 15 Sep 2026 00:00:00 GMT

Welcome to my personal website and blog!

For a long time, I’ve wanted a focused, distraction-free space on the internet to document what I’m learning, publish deep-dives into software engineering topics, and organize links to my work.

Why Astro?

When deciding how to build this space, my requirements were straightforward:

Speed and zero runtime bloat: Static HTML generation with minimal client-side JavaScript.
First-class Markdown & MDX support: Writing technical articles should be as friction-free as creating a Markdown document in my code editor.
Typography & Readability: A reading experience inspired by editorial blogs like Akita on Rails and minimalist portfolios like Vasilios Syrakis.

Astro provides the perfect foundation. Paired with Starlight’s search engine (Pagefind) and expressive code highlighting, the site delivers blazing-fast performance and seamless dark mode by default.

// Clean, minimal site configuration
export const siteConfig = {
  name: 'Vitor Aleluia',
  focus: ['Systems Architecture', 'Distributed Systems', 'Developer Tooling'],
  theme: 'dark',
};

What You’ll Find Here

On this blog, I will be writing about:

Systems Architecture: Resilient distributed architectures, database trade-offs, and edge networking.
Developer Tooling: Workflows, compilers, type systems, and building tools that make engineers more productive.
Reflections & Notes: Real-world lessons from scaling systems and navigating software development.

Feel free to explore the Links page to connect on GitHub, LinkedIn, or via email. Thanks for reading!

Pragmatic Lessons in Distributed Systems & Reliability

Wed, 02 Sep 2026 00:00:00 GMT

When building distributed services, the fallacies of distributed computing remain ever-present: the network is never reliable, latency is never zero, and bandwidth is never infinite.

In this post, I want to outline three foundational lessons that have repeatedly proven valuable when architecting systems that must withstand failure gracefully.

1. Design for Partial Degradation

A common failure mode in modern microservices is cascading failures. If service A calls service B synchronously, and service B begins timing out, thread pools or connection pools on service A quickly become exhausted.

// Implementing circuit breaking and exponential backoff
pub async fn call_with_retry<T, F, Fut>(mut operation: F, max_retries: u32) -> Result<T, SystemError>
where
    F: FnMut() -> Fut,
    Fut: std::future::Future<Output = Result<T, SystemError>>,
{
    let mut attempt = 0;
    let mut delay = std::time::Duration::from_millis(50);

    loop {
        match operation().await {
            Ok(val) => return Ok(val),
            Err(e) if attempt >= max_retries => return Err(e),
            Err(_) => {
                attempt += 1;
                tokio::time::sleep(delay).await;
                delay *= 2;
            }
        }
    }
}

Instead of allowing an outage in one subsystem to take down the entire application, every remote call should adhere to three non-negotiable rules:

Strict, bounded timeouts: Never rely on defaults. Default HTTP timeouts are often infinite or measured in minutes.
Circuit breaking: Stop hammering a failing downstream dependency.
Graceful degradation: Provide a cached response, a stale fallback, or an informative degraded UI rather than an uncaught 500 error.

2. Idempotency at Every Layer

Networks duplicate packets, proxies retry requests, and message brokers deliver messages at-least-once. If your mutation APIs cannot safely receive the same request twice, you are guaranteed to corrupt data eventually.

Introducing an Idempotency-Key header on all modifying requests ensures that even if a network timeout causes the client to resend, the operation is executed exactly once.

3. Observability is More Than Raw Metrics

Dashboards with hundreds of graphs often obscure reality rather than illuminate it. What matters during an incident is:

High-cardinality distributed tracing (where is time being spent?)
Structured logs with correlation IDs.
SLO-based alerts tied directly to user experience (e.g. error rate percentage and P99 latency thresholds).

Investing in thoughtful observability early transforms debugging from speculative guesswork into targeted resolution.

Developer Ergonomics: Blending TypeScript with Rust

Tue, 18 Aug 2026 00:00:00 GMT

Writing robust software doesn’t have to come at the expense of developer happiness. Over the past several years, the software engineering landscape has seen a significant shift towards expressive, static type systems.

Two technologies in particular stand out in how they enhance engineering velocity while eliminating entire classes of bugs: TypeScript on the application layer, and Rust on the systems and performance layer.

The Power of Discriminated Unions

One of the greatest gifts of TypeScript’s type system is algebraic data types represented through discriminated unions. Rather than passing nullable fields and hoping callers inspect them, we make invalid states unrepresentable:

type Result<T, E> =
  | { success: true; data: T }
  | { success: false; error: E };

function handleApiResponse(response: Result<{ id: string }, Error>) {
  if (response.success) {
    // TypeScript automatically narrows the type here
    console.log("Resource created:", response.data.id);
  } else {
    console.error("Operation failed:", response.error.message);
  }
}

This pattern maps directly to Rust’s native Result<T, E> enum, making mental context switching between the two languages remarkably intuitive.

Bringing Native Performance to Tooling

In developer tooling, performance is a feature. When test runners, linters, or code generators take minutes, developers lose their flow state. By rewriting critical paths in Rust or leveraging WebAssembly, we can compress feedback loops from minutes to milliseconds.

The future of software tooling is fast, type-safe, and delightful to use.