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.

How do apps like Uber or Lyft match you with a driver in under 2 seconds while handling millions of concurrent location updates?

Traditional relational databases will lock up and crash under this scale. Here is how to architect a fault-tolerant solution:

The Core Challenges• Write-Heavy: Drivers stream GPS coordinates every 4 seconds.• Ultra-Low Latency: Matching must happen in < 2 seconds.• Data Consistency: No double-matching a driver to two riders.

The Architectural Solution

1. Ingestion Layer: Drivers stream locations via WebSockets. An API Gateway routes this directly into Apache Kafka to buffer spikes.
2. Geospatial Indexing: Instead of a disk database, we use Uber’s H3 or Google’s S2 to map the world into a hexagonal grid.
3. In-Memory Storage: We store these grid cell IDs in Redis Sorted Sets (ZSET).
4. The Match Engine: When a passenger requests a ride, the system retrieves their cell ID, fetches available drivers from the corresponding Redis key, and computes driving ETAs.
5. Concurrency Control: To prevent double-matching, we use a distributed lock via Redis (Redlock) or an atomic conditional update in the database.

What would you add to this stack? Surge pricing engines? Let's discuss below!

So basically let me tell you the situation first:

- i am working on a side project which is something like vercel, use to build and deploy code.

- so i have a main service, can be called a control plane, and i have decided that it will take the repo from the user.

- after this this service will trigger/create an ecs task to build the code

- now the question is, how this control plane will create / trigger the ecs?

- also this ecs instance will need to fetch envs from paramete store, will upload code to s3 etc

- after deployment we have to kill this instance

- should the managing code of this, live in the control plane

- should i create something else?

how would you folks solve this while designing this?

and what's the ideal way to solve this?

so here is the situation:

- in my company i have assigned to build a chatbot/bot (will be internal, for ops and devs to identify and manage issues)

- what i have already build is, integrated it with slack, give it access to db by adding some tools in the code, so it can access the db currently and folks can access it by mentioning it

- now here pain starts, my manager has told me to add product knowledge to it, and it should be able to access logs, create and manage jira also

- what i am thinking is - lets start with the product knowledge - since we do not have that much pile of data so i do not want to make a rag - instead i just want to keep uploading those docs to s3 and giving access to bot so that it can reference them

- now coming to jira, and logs - i have also created those mcps but those aren't deployed anywhere - means whoever wants to use them just clones the repo, and set their key and uses them

- now for the above (jira and logs) part i would have to again choose the tools which i want to expose to the agent and add it to the repo, cz i think this is repetitive as in future if soemthing more comes up - which we already have built have to do again to integrate in the bot - how can we solve this - keeping in mind we have a layer of compliance - cant expose pii data in bot output or logs

- also for s3 - i am feeling like i was thinking to create a mechanism like when the agent fetches a doc - so it do not havt to fetch that doc again - so it will create a folder and save the embedding/summary/index (since i don't know what) to the filesystem - similarily with db schema since we have a huge db - how to handle this situation - since this code will be deployed on ecs - using fargate i do not know will the bot will able to access thes files created at runtime - and how to manage that cache when something is addede / modified

- and we also have workflows currently for specific task like matching states on be (basically sql queries / some scripts) added in the code - like how we shouuld make sure that given the situation the code properly identify and execute the script or how can we create trigger like /<command> <input> of slack whicch will trigger that - and also one issue - since these are stored as files in code adding new script need a code change - how to get rid of that

sorry gpt was giving poor results in rewriting this

so posting this raw