Monika Čolić

My fellow principal engineer Arron Bailiss wrote an excellent blog post about the design principles of Strands Agents 🧬, what the agentic "model-driven approach" means, and guidance for how to think about multi-agent architectures. https://lnkd.in/gh5p5UXi

262

3 Comments

Since announcing my "High-Performance Node.js" workshop last week, I've received dozens of messages from enterprise developers facing the same critical challenge: "How do we identify event loop blocking in production before it becomes a crisis?" This is precisely the real-world problem separating junior developers from senior engineers. Let me share what I tell enterprise teams. The Three Warning Signs I Look For: 🚨 Response Time Spikes with Normal CPU Usage When your APIs start timing out but your servers aren't maxed out, you deal with event loop blocking. The server has capacity but can't process new requests because the event loop is stuck. 📈 Memory Growth Over Time Blocked event loops often cause promise queues to build up, creating memory leaks. Because of this single issue, I've debugged Node.js applications consuming 8GB+ RAM. Your monitoring should track memory trends, not just point-in-time usage. ⚡ Inconsistent Response Patterns Some requests complete in 50ms, while identical operations take 5+ seconds. This inconsistency is a classic indicator that something is intermittently blocking the event loop. The Real Solution Goes Beyond "Just Use Async/Await" Most developers think proper async/await usage solves everything. However, enterprise applications need comprehensive instrumentation, strategic worker thread implementation, and a deep understanding of Node.js internals. We'll tackle this in my workshop on September 29th in London. We'll debug real scenarios, implement proper monitoring, and build applications that perform consistently under production load. For enterprise teams dealing with Node.js performance challenges, this workshop bridges the gap between theoretical knowledge and production reality. 📅 September 29th | London | 4 Hours Intensive 🎯 Limited seats available Register: https://lnkd.in/d7A6wr2K What's your team's biggest Node.js performance challenge? I'd love to hear about it in the comments.

71

1 Comment

Every now and then, it’s worth stepping back to revisit the fundamentals. Mostly because too many core concepts are still being misunderstood, especially as #EventDriven systems become more popular. One of the most common confusions I see is between messaging and event-sourcing. Many engineers still believe that just because they’re using #Kafka or #RabbitMQ, they’re “doing event sourcing.” Or that building a message-driven system automatically means they’re applying event-sourced principles. Let me be clear: - Messaging is a transport concern. - Event Sourcing is a persistence strategy. #Messaging is what you use to communicate between components, services, or bounded contexts. It’s how you react to state changes and trigger distributed behaviors across your system—a foundational part of reactive and event-driven architectures. #EventSourcing, on the other hand, is how you persist state. Instead of storing the current state in a table, you persist each state transition as an immutable event, and reconstruct the current state by replaying them. It’s not about integration. It’s about history, auditability, and intent. So, no, your event store is not a message broker. And your message log (even if it's Kafka) is not an event store. They serve different purposes and come with different design implications. Of course, these two concepts can and often should be combined. You can persist your events using event sourcing, and then publish them to a message broker to integrate with other parts of the system. That’s a powerful pattern, but it doesn’t mean one replaces the other. Clearing up this confusion is more important than ever. The tools we use may evolve, but the fundamentals still matter. And understanding the difference between message-driven communication and event-sourced persistence is one of them. Let’s raise the bar! #EventDrivenArchitecture #DistributedSystems #ReactiveDDD

77

8 Comments

Today I published "Crafting Your Software", a deep-dive into Canonical's "craft" tools, and how they can be used to build a huge variety of software projects into lots of different kinds of artifact, with a common grammar and CLI experience. The crafts are fast becoming a critical part of the #Ubuntu developer experience, whether you're contributing OCI images, Snap packages or Debs. Take a look on the Ubuntu discourse! https://lnkd.in/ewkwAEWh

50

1 Comment