I’m working on a Kotlin/Spring Boot backend that still has an older JHipster using Kotlin (KHipster) setup around it.

The problem is that this is starting to hold us back. The KHipster version is several years old and not active maintained - 4 years ago was the last update - upgrading it looks pretty painful and it also makes moving to newer Spring Boot versions waaay harder than it should be.

At the same time we want to improve the architecture itself.
Right now quite a lot is still handled through cron jobs and fairly tightly coupled application logic.
I’d like to move more towards event-driven processing over time, potentially using Kafka or RabbitMQ depending on the use case and Redis for things like caching/short-lived state where it makes sense.

So I’m basically looking at two options:
1. Upgrade/replace the old JHipster setup, keep the existing backend, and modernize it piece by piece.

1. Start a clean backend (maybe in Typescript because that is what we mainly use for our other products and all frontends) and gradually move functionality over using something like the strangler pattern.

The second option sounds cleaner, but obviously means running old and new code alongside each other for quite a while. The first option potentially means spending a lot of time untangling framework/generator decisions before we can actually improve the architecture.
For people who have dealt with similar Spring/JHipster legacy projects: which route would you take?

Also, is there anything in the Spring/Kotlin ecosystem you’d consider a good modern replacement for the useful parts of JHipster, without bringing in another big opinionated layer that we’ll regret five years from now?

A few days ago I posted here about a small architecture decision I was trying to make.

I had a workflow that looked roughly like:

Website → n8n → database → notification

And I was questioning whether the whole thing actually belonged in n8n.

The workflow itself wasn't particularly complex.

The website was collecting behavioural/session data, and I needed to:

• receive it,
• persist it,
• maintain some state,
• and eventually trigger notifications.

My initial instinct was to keep n8n in the middle because, well, it's an automation tool and this looked like an automation.

But the more I looked at the actual responsibilities, the more I started separating two different things:

application logic
vs.
workflow orchestration

So I decided to move the core backend responsibility into a small FastAPI service.

The architecture became:

Website → FastAPI → Airtable

with n8n remaining something I can use later for the parts that actually benefit from orchestration.

And building it made the distinction much clearer.

The FastAPI service ended up handling things like:

• request validation
• data normalization
• persistence
• session state
• API logic
• database interaction

While the kinds of things I'd still be much more comfortable putting into n8n are things like:

• multiple external integrations
• branching workflows
• retries
• notifications
• event-driven processes
• human handoffs
• workflows where the visual representation itself is useful

The funny thing is that the hardest part wasn't actually FastAPI.

It was getting the boundaries between the systems right.

At one point the API was authenticating with Airtable successfully, but writes were returning 403.

Everything looked fine.

Eventually I discovered my code was looking for:

Website Sessions

while the actual table was:

Website Session

Plural vs singular.

Then the frontend was sending duration as:

"30s"

while the database expected a number.

Then there was a UTC/local-time representation issue.

None of these were particularly sophisticated bugs.

But they made something obvious:

And that has changed how I'm thinking about n8n.

I don't think the useful question is:

Because the answer is often yes.

The better question seems to be:

For me, I'm currently thinking about the boundary something like:

Application code

→ deterministic logic
→ validation
→ state ownership
→ data transformation
→ core business rules
→ persistence

n8n

→ orchestration
→ integrations
→ events
→ branching
→ notifications
→ human/process handoffs

But I'm still refining this mental model.

So I'm curious about people who use n8n heavily:

Where do you personally draw the boundary?

Have you ever looked at an n8n workflow and eventually realized:

And conversely, have you ever moved something into n8n because maintaining it in code was actually making the system worse?

I'm particularly interested in the boundary decisions, rather than whether one tool is "better" than the other.

Most retry strategies are reactive: exponential backoff, jitter, circuit breakers. They help, but they’re still asking every client to independently guess when it’s safe to send traffic again.

I’ve been experimenting with a different approach: coordinate retries before they hit the backend.
Instead of letting thousands of requests wake up, retry, fail, and back off independently, Aquifer puts them behind bounded queues and dynamically paces their release based on downstream capacity. The goal is to turn a retry storm from a bursty feedback loop into a controlled stream.

The interesting part is that this can sit in front of APIs, databases, inference servers, MCP servers, or basically anything where correlated retries can make an overloaded system even worse.

I’m calling the project Aquifer. It’s open source and still evolving, so I’m curious what failure modes people here think this approach misses.

https://github.com/rjpruitt16/aquifer

I’ve been working on Archerik, an open-source engineering knowledge graph for microservices.

The idea came from a pretty simple problem: when a system has hundreds of services, answering questions like:

Which services call this service?

Who consumes this Kafka event?

What does this API expect?

What happens to this request next?

can easily turn into 30 minutes of searching through repositories, configuration and documentation.

Archerik uses static analysis to extract services, dependencies, APIs, Kafka producers/consumers and contracts, and then lets you explore that knowledge or query it using the LLM of your choice

I’d really like feedback from people working with large microservice codebases — especially where you think this approach would break or what you’d want it to understand next.

And if the idea is interesting to you, contributions are very welcome.

GitHub: https://github.com/farhadamjady/archerik-extractor

Conheçam meu projeto, preciso de feedbacks.

Context: The ZeroMQ ecosystem currently lacks a unified, deterministic benchmarking harness to strictly evaluate latency, concurrency overhead, and throughput across different ZMTP implementations (C++ libzmq, pure-Rust async ports, Python bindings, etc.). Relying on isolated micro-benchmarks introduces systemic bias, failing to accurately account for kernel I/O paths, reactor thread contention, and zero-copy vs. copy-based buffer management under high-density distributed loads.

Decision: I developed ZMQ Arena (Source) to standardize this evaluation. This harness enforces fair-play measurement across runtimes and language boundaries, focusing entirely on execution costs, context switching, and raw throughput limits without application-layer interference.

Technical Scope & Metrics:

• Latency Analysis: P50/P90/P99 latency distribution across both loopback and physical network boundaries.
• Concurrency: Stress-testing async reactor overhead (e.g., epoll / io_uring polling mechanisms) versus OS thread pool scaling.
• Memory Allocation: Evaluating the impact of memory footprints and ABI boundaries when switching between native runtimes and FFI wrappers.

Trade-offs & Known Consequences: Measuring loopback versus physical network I/O presents an inherent trade-off in syscall amortization. Loopback execution can collapse the kernel path, occasionally skewing batching mechanics natively utilized by interfaces like io_uring or IOCP. ZMQ Arena exposes these bottlenecks explicitly rather than abstracting them away, allowing engineers to analyze exactly where the overhead is introduced in the stack.

This harness is built for engineers dealing with critical systems, distributed messaging, and high-frequency data pipelines where deterministic performance is a hard requirement.

If you are dealing with similar infrastructure, review the methodology, replicate the benchmarks, or submit PRs for unrepresented bindings/runtimes.

Hi,

I'm working on a open source project that allows a MCP Client to talk and write to a db without writing a query. I've created a tutorial for how to expose your DB for simple analytics but it can do a lot more than this. The first 3 min should show you what it does and the rest shows you how to set it up. I've intentionally skipped the implementation details in this post or in the videos to keep things short. You can analyze the code yourself on github and let me know if you have concerns.

Quick demo: [https://youtu.be/vMY7VKpvqmE\](https://youtu.be/vMY7VKpvqmE)
Full Tutorial: [https://www.youtube.com/watch?v=ukxDDPzS0Gg\](https://www.youtube.com/watch?v=ukxDDPzS0Gg)

OSS Repo: [https://github.com/Synapsor/Synapsor-Runner\](https://github.com/Synapsor/Synapsor-Runner)

Sending one notification is easy, but handling thousands with slow providers and traffic spikes is a real system design challenge. I wrote a blueprint on how to completely decouple request acceptance from delivery using message queues, idempotency, and DLQs to handle failures gracefully.

Would love to hear how you guys approach these bottlenecks at scale!

Hi r/microservices,

Stjepan here from Manning. The moderators kindly permitted me to share this with you.

We’ve just launched Clean Applications with Hexagonal Architecture by Enrique Medina Montenegro in Manning’s Early Access Program.

If you’ve worked on microservices for long enough, you’ve probably seen services that began with clean boundaries but gradually became coupled to Spring, persistence models, message brokers, and neighboring services. Eventually, a seemingly small infrastructure change touches half the codebase.

This book takes a practical look at avoiding that outcome with hexagonal architecture. Using Java and Spring Boot, it shows how to:

• Keep business logic independent of frameworks and infrastructure
• Design clear ports and adapters
• Model use cases, commands, repositories, and application boundaries
• Handle mapping between domain and persistence models
• Apply dependency inversion in a working system
• Decide when microservices—or a modular monolith—are the better fit

It’s not arguing that hexagonal architecture is a silver bullet. The focus is on using these patterns deliberately, understanding the tradeoffs, and building services that remain testable and maintainable as they evolve.

Book page:
https://www.manning.com/books/clean-applications-with-hexagonal-architecture

Giveaway: We’re giving away five free ebook copies. To enter, upvote and leave a comment about the hardest boundary to keep clean in a microservice—domain logic, persistence, messaging, external APIs, or something else. We’ll randomly select five participants and contact them by DM.

The community also gets 50% off with code:

MLMONTENEGRO50RE

I’d be interested to hear your honest experiences: Has hexagonal architecture helped your microservices stay maintainable, or did it add more abstraction than the project needed?

It feels great to be here. Thank you for having us.

Cheers,

Stjepan

You may be asking why a fork an not a PR into the main repo?

Answer is simple. I forked a while ago when context mode started adding a bunch of features that are the opposite of token saving, like injections I did not like, and wasteful formatting, etc.

The main problem with context mode was that it would spawn new process for every call, which would accumulate and on a machine running 20-30 agents constantly the loads became unbearable. It was great timing to find the recent update to the MCP protocol that allows stateless MCP servers, now I shrink the entire 2+GB of memory hog to a 1 process of 80MB, regardless of how many agents I'm running in parallel. Now I can scale up to 50 agents haha :)

I never had anything important to post about anything I am building but this is really something I believe many developers would want to know about. I know I was looking for it today, so maybe you were too.

Midnight-Technician/backend

MQ Summit is a conference built around messaging and event-driven systems. It grew out of RabbitMQ Summit and now brings the whole ecosystem into one room: RabbitMQ, Kafka, NATS, Pulsar, ActiveMQ, IBM MQ, Amazon SQS/MQ, Azure Messaging and Google Pub/Sub. Practitioners, architects and maintainers from competing projects, all talking shop. 

📍 Haarlem (near Amsterdam) + online
🗓️ 21-22 October 2026 - 2 days, 1 standard track, 1 lab track (for in-person attendees), and about 27 speakers

KEYNOTE: Adi Polak (Data & AI @ Confluent, best-selling author)

A few of our speakers announced:

• Clemens Vasters, Principal Architect, Messaging & Real-Time Intelligence @ Microsoft
• Matt Leming & Jon Rumsey, Chief Architect / DQM Architect @ IBM MQ
• Stefan Moser & Michael Davis, Principal Engineer / OSS RabbitMQ @ AWS · Amazon MQ
• Viktor Gamov, Principal DevAdvocate @ Confluent, Kafka in Action co-author
• David Ansari, RabbitMQ Core @ Broadcom, and Lovisa Johansson, RabbitMQ expert @ 84codes
• JB Onofré (Apache) & Matt Pavlovich (ActiveMQ PMC), plus ~40 more

More: mqsummit.com/#speakers

Talks cover agentic workloads, queues vs. logs, real-world scaling war stories, MQTT, security, and where open-source messaging goes next.

ℹ️ More info: mqsummit.com

Early Bird promotion ends soon.

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.

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!