Posts

Microservices architectures promise flexibility, scalability, and agility in software development. But with this flexibility comes significant complexity—especially when managing transactions across multiple, distributed services. Today, let’s talk about the history of distributed transactions, diving deep into two powerful yet contrasting approaches: Choreography and Orchestration. Why Distributed Transactions? In the beginning, monolithic applications reigned supreme. Transactions were straightforward—everything operated within a single database, making transaction management relatively easy. But as software applications grew in scale and complexity, a single database was no longer sufficient. Distributed systems emerged, scattering services across various databases and networks, making the once-simple transactions suddenly intricate and challenging. ...

In the early days of software development, many teams measured the health of their applications through a single lens: logs that printed cryptic messages whenever something went wrong (or occasionally when something went right). Over time, as systems grew more complex and needs broadened, engineers embraced additional approaches, like metrics that could highlight performance trends and spikes. Eventually, logs and metrics alone were no longer enough. Distributed systems, microservices, containers, and orchestrators demanded a whole new way of understanding application behavior. This is how the idea of Observability started to take shape—an effort to see right into the beating heart of the system and know exactly what’s going on, without guesswork. ...

The day I first heard about event-driven architectures, I imagined a busy marketplace where each stall (service) would broadcast its daily specials (events), waiting for eager passersby (consumers) to snap up the deals. Over time, that humble metaphor soon expanded into real-world engineering decisions: do I rely on a queue-based system like RabbitMQ, or do I step into the realm of event logs with Kafka? Let’s explore these two messaging heavyweights and see why choosing between them often comes down to more than just performance metrics. ...

TL;DR Embark on a narrative journey through distributed systems to uncover the subtle differences between messages, commands, and events. Discover how these concepts weave into the fabric of microservices architecture, illustrated through a real-world e-commerce story. Learn to make strategic decisions for your projects without getting lost in technical issues. Introduction Imagine a robust marketplace where merchants, couriers, and town criers all play pivotal roles in keeping the economy alive. In this scenario, communication is key. Messages are exchanged, commands are issued, and news of events announced. This lively marketplace is a metaphor for distributed systems, where understanding the nuances between messages, commands, and events is crucial for building effective microservices architectures. ...

Preface A friend of mine recently asked for my consultation on creating a roadmap for them on how to contribute to a big open-source project like the Linux kernel. I took the chance and tried drafting a simple blog post of what I thought would be a good general guideline to approach such a task. Contributing to the Linux kernel can feel like an overwhelming challenge. After all, it’s one of the most complex and influential pieces of software in existence, powering everything from smartphones to supercomputers. But for those with a passion for Linux and open source, becoming a contributor is not only possible, it’s incredibly rewarding. Whether you’re looking to improve your knowledge of operating systems, sharpen your coding skills, or simply give back to the community, this guide will walk you through the steps you need to take to make your first contribution to the Linux kernel. ...