Architecture

A few days ago I attended a small, invite-only tech gathering hosted by Cafe Ertebat. Think of it as a low-key salon: about a couple dozen people, all of them with at least a decade of experience, almost all with shiny titles: CTOs, VPs of Engineering, technical leads, founders. It was the kind of room you’d expect to be intimidating. It wasn’t. And that was the interesting part. Walking into an “Elite” Room I was invited through two friends and colleagues who referred me to the host. That alone set a certain expectation in my head: if this is curated, and everyone is hand-picked, then the conversation is probably going to be sharp, opinionated, and uncomfortably insightful. ...

I was midway through a system-design talk when a familiar question landed: So… is DDD an architecture or a pattern? The room had many .NET folks. Heads tilted. Some smiled the “here we go” smile. Let’s answer it simply, and then go a little deeper; without buzzword gymnastics. A simple definition of DDD Domain-Driven Design (DDD) is a way of designing software by centering everything on the language and rules of the business. It gives you two kinds of tools: ...

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. ...

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. ...

Introduction In the ever-evolving landscape of software development, tracking changes to data is a fundamental requirement. Whether for auditing, debugging, compliance, or analytics, maintaining a history of changes enhances transparency and accountability within a system. Two prevalent approaches to capturing these changes are storing a change log and using event sourcing. While they share common goals, they differ significantly in implementation and suitability depending on the system’s needs. This blog post delves into the similarities and differences between change logs and event sourcing, assesses their applicability through practical examples, and provides guidance on choosing the right approach for your system. ...

The professional path of a Software Solutions Architect I’ve been working in software for more than 12 years now. I’ve been doing help desk stuff, database management, IT work, networking, low-level and high-level programming, hacking and penetration testing and everything in between. All these experiences and upportunities that I have had, helped me becoming me more well-rounded engineer which is a cruitial attribute to have if one wantes to embark on the mission to becoming an architect, specially a Solutions Architect. ...