Andrea Sosi

If you're working on a complex software project, having good architecture diagrams really helps. And in this guide Alex explains what the C4 model is & how it works. You'll go through each level - context, containers, components, & code - in detail. https://lnkd.in/ef34fiwF

260

5 commenti

✨ First open source PR in years. First blog post ever. First time adding Cassandra support to Testcontainers-dotnet? Yep, Gavin de Kock just did all three. And it was smooth sailing. 🚢 From spotting a missing module to contributing it with ease, Gavin shares how friendly the Testcontainers OSS community is—and how simple it is to spin up Apache Cassandra for .NET integration testing using Docker. A fun read and a great reminder that open source is open for everyone. 🙌 Check out the post and try it yourself: http://spklr.io/6048APQn #Docker #Testcontainers #OpenSource #DotNet #ApacheCassandra #IntegrationTesting #DeveloperExperience

40

2 commenti

Give me 10 sec, I will tell you. If a single user is sending too many API requests and causing high load, we need to protect the system to keep it stable for all users. Answer: The first solution is rate limiting. This means we allow only a certain number of requests per user in a fixed time window, like 100 requests per minute. If the user exceeds that, we block or reject further requests for some time. This prevents any one user from overloading the system. Another approach is throttling, where instead of blocking, we slow down the user’s requests after they cross the safe limit. This helps reduce the pressure on the system while still allowing limited access. We apply these limits based on the user ID or IP address. It's better to use user ID if available, as many users can share the same IP (like in offices or public networks), and blocking IPs might affect innocent users. We can also use algorithms like Token Bucket or Leaky Bucket to manage request flow. These allow short bursts of traffic but enforce limits over time to avoid abuse. In addition, we can log and monitor API usage. If someone is abusing the system regularly, we can alert the team or block the user permanently.

59

2 commenti

Why Akka.NET is the Best Choice for Reactive Systems in C# .NET 9 In the era of cloud-native, distributed, and high-availability systems, reactive architectures are no longer optional — they're critical. And Akka.NET remains one of the best choices to bring this power to C# and .NET 9! 🚀 Here’s why: 🔹 1. True Asynchronous, Message-Driven Architecture Actors encapsulate state and behavior. Communication happens via asynchronous message passing, which removes tight coupling and shared memory issues. (Image 1) 🔹 2. Built-in Fault Tolerance and Resilience Failures are expected — Akka.NET embraces them through actor supervision strategies. Parent actors supervise and manage failures gracefully. (Imagem 2) No need for scattered try/catch logic — resilience is centralized and structured. 🔹 3. Horizontal Scalability with Akka.Cluster and Sharding Scale your actor systems transparently across multiple nodes, supporting millions of actors efficiently. (Image 3) Perfect for microservices, cloud deployments, and elastic scaling. 🔹 4. Modern .NET 9 Performance Optimizations Akka.NET now fully embraces improvements like: System.Threading.Channels for high-throughput messaging. Better async/await context-switching. Native AOT (Ahead-Of-Time Compilation) readiness for faster startup times in containers. 🔹 5. Event Sourcing and CQRS Support With Akka.Persistence, you can naturally implement event sourcing and CQRS patterns without complexity. 🔹 6. Developer-Friendly and Production-Ready ✅ Test actors with Akka.TestKit. ✅ Deploy actors with Akka.Remote. ✅ Monitor health with Akka.Monitoring. ✅ Handle backpressure automatically with Akka.Streams. 🔥 Summary If you need a system that's responsive under load, resilient to failure, scales elastically, and embraces cloud-native principles — Akka.NET + .NET 9 is a battle-tested, future-proof choice. Example: Deploying a simple cluster-based order processing system with supervision, event sourcing, and elastic scaling — all natively, without reinventing the wheel! 💬 Have you considered actor-based architectures for your next high-scale project? Let’s connect and share experiences! #microsoft #developer #csharp #netcore #dotnet #dotnetcore #softwaredeveloper #softwareengineer #dotnettips #aspnetcore #tech #backend #softwarearchitecture #solidprinciples #cleanarchitecture #softwareengineering #akkadotnet #reactiveprogramming #cloudnative #resilientsystems #microservices #distributedcomputing

53

4 commenti

Your Business Logic Is a Legacy Bomb Business logic is like glitter, once it’s in your codebase, it never leaves. Yet developers mix it with frameworks, AOP, JPA lifecycles, and even annotations as if that’ll age well. Spoiler: it won’t. Make logic explicit. Ban black magic. Kill hidden behavior before it kills your updates and your maintainability. Services should be boring. One responsibility. One intent. Not some god-class that knows 20 repositories and calls three clouds before breakfast. Isolate business logic. No, your entity is not a DTO in disguise. It should do something. Rules? Extract them, Strategy pattern, DSLs, Rule Engines. Variation? Externalize it. Sharing? Yes, even your beloved GitHub Actions. Reuse, don’t regurgitate. Frontend and auth layers should choke on business logic. The backend? A cold, lifeless BLS (Business Logic Service) or BFF. Keep core services stupid. Stupid scales. Stupid survives. And infrastructure logic? Out. CORS, HTTPS, tracing, pipelines,… should never haunt your domain logic. One place. One purpose. Fewer edge cases. Fewer WTFs. Databases are for persistence, not clever tricks. Your dishwasher doesn’t run Spring Boot. Neither should your repositories. You build tool has cool features? Ignore them, it should just build and your service should be dump and fast enough to build. No special feature pays in long term. Want maintainability? • No black magic. • No framework entanglement. • No accidental architecture. Just stupid simple, reusable, testable, measurable and boring code. That’s the dream. Because when your object mapper changes naming strategy and you wake up to a 500 error, you’ll remember this post. “You build it, you run it.” Just doesn’t mean you have to build a mono repository monster. DX is more important than performance as developers are expensive not the numbers of instances.

38

7 commenti

#ADRs (Architecture decision record) are like event sourcing. ADRs are written down decisions about architecture. Why did you chose React? Why not Angular? What were the Pro and Cons and why was that solution the winner? They make it easy for developers new to the company or new to the team to understand the decisions BEHIND the current tech stack and architecture. So they can make better decisions themselves. A side effect of ADRs is that you do not have the same discussion over and over again. How are they like Event Sourcing? ADRs have not the downside of normal documentation. Normal documentation is hard to keep in sync with reality. It's a tedious process, and nearly impossible if you did not find the right level of documentation (deep enough, but not too deep). ADRs do not change. They are write-one-read-often, they are read only. They don't need to be maintained, they are always correct. In this way they are like events in Event Sourcing. Those also do not change. And ADRs can be seen as an event, and to get an understanding of the current state of your architecture, you need to read and aggregate those ADRs, just like events in event sourcing. https://adr.github.io/

28

2 commenti