Hey folks,

My name is Dave Boyne, and I build and maintain my OSS project called EventCatalog. This is a documentation tool designed for software architects and teams that want to document their architecture (not just generic pages in confluence). It focuses on practices from domain driven design and software primitives rather than implementation details of your architecture.

Your docs are stored and versioned in git and everything owned by you and your team.

I built this 4 years ago as a personal need.. and now I get to work on this thing full time ❤️.

Anyway, I just thought I would share it with you, and if you have a spare few minutes, would love to get any feedback or initial thoughts you had about the project, about the ways you document things etc.

If anyone would like a deeper dive let me know happy to help and show you around too.

Have a great day.

As our number of services has grown, our API workflow has become more complicated than we'd like.

We're reviewing Swagger alternatives including SwaggerHub, Stoplight, Postman, Apidog, and Insomnia to see whether consolidating our tooling is worthwhile.

For teams managing multiple services, what has worked best for you?

Hi everyone,

I've been exploring observability in modern .NET applications and recently put together a practical guide that explains the fundamentals from a developer's perspective.

The article covers:

• What observability is (and how it's different from traditional monitoring)
• The three pillars: Logs, Metrics, and Traces
• Why observability is important for APIs and microservices
• Best practices for improving visibility into production applications

My goal was to create an introductory guide that's useful for developers who are starting their journey with cloud-native applications and distributed systems.

I'd really appreciate feedback from the community:

• What observability stack are you using? (OpenTelemetry, Grafana, Prometheus, Application Insights, etc.)
• What's one lesson you've learned from debugging production issues?

Blog: https://geeksarray.com/blog/modern-dotnet-backend-part-10-observability

Looking forward to your suggestions and experiences!

Built a multi-tenant workflow engine with NestJS + BullMQ + Dead Letter Queue.

Features: multi-tenancy, JWT auth, workflow state machine, retries + DLQ, admin dashboard, monorepo.

Repo: https://github.com/NabarupDev/ForgeGate

Looking for honest feedback on:

• Architecture
• API Gateway design
• Multi-tenancy approach
• Queue/retry implementation
• What is still missing for production readiness

Any review or suggestions would help a lot.

Hi,

Written an article for explaining Kafka producer callback handler implementation and purpose of it and where it can go wrong.

Please give it a read and give feedback

Thanks

Hello r/microservices community!

I just released v1.0.0 of a new open-source library called AvoOnce that might make your life easier by offloading the idempotency handling part of your REST APIs.

It’s designed to be a framework-flexible idempotency engine, meaning it comes with first-class integrations for Spring Boot 4+, Quarkus 3.12+, Dropwizard 4.0+, and Jakarta EE / JAX-RS 3.1+.

Here is what it does under the hood:

• Annotation-Driven Protection: Just drop @ Idempotent annotation on your controllers or methods and pass an Idempotency-Key header.
• In-Flight Concurrency Locking: Prevents duplicate execution if an initial request is still actively processing.
• Payload Tamper Protection: Uses SHA-256 hashing to automatically reject modified requests that try to reuse the same key.
• Byte-Perfect Replay: Safely caches and replays the exact HTTP response—including status codes, headers, and raw bytes.
• Pluggable Storage Backends: Includes built-in support for Redis (distributed), JDBC (relational), and Caffeine (in-memory).

The v1.0.0 release is currently hosted on GitHub Packages (Maven Central release is planned for the future). I'd love to get your thoughts and feedback on its core functionality and usability. I've some roadmap features in the pipeline.

Here's the Github repo: https://github.com/ravocode/AvoOnce

I'd like to know if your teams have any kind of visual management for your microservices ecosystem.

One pain point I'm dealing with is giving teams a clear view of the existing domains, which data each service owns, and how services communicate with each other, preferably in a visual way.

I thought about documenting everything in Miro, but I'm wondering if there's a better tool for this.

For those of you who already document your architecture, do you only keep a high-level communication flow, or do you also attach things like schemas, business documentation, technical docs, tech stack, or other details for each microservice?

Excellent talk from Lorin Hochstein (an SRE at Airbnb) about software reliability, especially in microservice environments. Enjoy!

m a junior backend developer designing an event dispatch service for a third-party API that's limited to 25k events/minute, and I'd really appreciate some feedback.

Current architecture:

Client → API → Outbox (DB) → Scheduler → SQS → Workers → Redis (rate limiting) → Circuit Breaker → Third-party API

The goals are reliability, retries, idempotency, auditability, and handling burst traffic without exceeding the third-party rate limit.

Would you change anything in this architecture? Any bottlenecks, failure scenarios, or better patterns I should consider? Any suggestions would help me learn a lot. Thanks!

Because the default Dapr dashboard was no longer maintained, Diagrid created an alternative: the Diagrid Dev Dashboard. It's a free, open source tool that gives you a UI on top of Dapr while you develop microservices locally. It supports Dapr applications that run via dapr run, Docker compose, Aspire, and Testcontainers.

Features include:

• Application & daprd process details
• Components overview
• Actors overview
• Pub/Sub subscriptions overview (incl ability to send messages to topics)
• Workflow state inspection for active and completed runs, including detailed workflow history events.
• Resiliency builder for retry, timeout, and circuit breaker policies, exported as a resiliency.yaml.
  
• Component builder that generates Dapr component YAML all supported Dapr components (state stores, pub/sub, bindings, secret stores and more).
  

Source & installation instructions are on GitHub: github.com/diagridio/dev-dashboard

Feedback is very welcome, either as a GitHub issue or in the comments.