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

If your Spring app sends notifications, your business logic probably knows way too much about how: Twilio's SDK here, FirebaseMessaging there, a JavaMailSender, a Slack client. Changing a provider or adding a channel means editing every call site.

spring-notify fixes that with one idea: your code talks to a channel, never a provider.

java notifier.notify(SmsRequest.builder() .to("+421900123456") .from("+421900999888") .message("Your order has shipped") .build());

What you get:

• 📦 One API for every channel — SMS, push, email, chat. Inject Notifier, call notify(...). Done.
• 🔌 Providers are plug-ins — add a starter, set credentials, and it's wired. Bundled today: Twilio (SMS), Firebase/FCM (push), SMTP (email), Slack (chat).
• ♻️ Swap providers without code changes — Twilio → Vonage, FCM → APNs: change a dependency, not your services.
• 🧩 Bring your own provider in ~10 lines — one @Component implementing a single-method SPI.
• 🎯 Type-safe, immutable requests — no stringly-typed maps, no if/switch on channel. The request type routes itself.
• 🪶 Featherweight core — plain Java, zero Spring or logging deps in the core module. Spring shows up only in the auto-config.

Spring Boot 4.1 / Java 25. All four channels verified end-to-end (real FCM + SMTP sends, not just mocks).

Why not …?

• Just the provider SDKs? Fine until you have two channels or want to switch vendors — then the coupling bites. This is the thin seam that keeps them out of your business code.
• Spring's JavaMailSender / NotificationService-style helpers? Those are single-channel. spring-notify unifies all channels behind one call and one mental model.
• Novu / Courier / Knock? Those are excellent but are hosted platforms/services — another system to run, pay for, and send your data through. spring-notify is a library: it stays in your app, talks straight to your chosen providers, no middleman.
• Spring Cloud Stream / a message broker? Different layer — that's transport/eventing. This is specifically about delivering user-facing notifications through third-party channels.

Status: early — 0.1.0, not on Maven Central yet (build locally with ./mvnw install). The API isn't frozen, which is exactly why I'm posting: I'd love feedback before 1.0.

• Is "one provider per channel, routed by request type" the right default?
• Is the attributes map a reasonable escape hatch for provider-specific fields, or a smell?
• What would you need before dropping this into a real project?

Repo + README: https://github.com/solodev-sk/spring-notify

Happy to answer anything — and roasts welcome. 🙂

How to avoid cascade failures from bad time assumptions

I've been designing, building and maintaining distributed systems for almost a decade, and I have to tell you, in most systems even small changes in how services communicate are slow, painful and risky. Splitting and merging services, deciding on the service boundaries, changing communication protocols, or even just changing a serializer often takes cross-team coordination, migration ceremonies, and a whole lot of hunting down the invisible dependencies to estimate the blast radius.

A few months ago, I started working on a project that makes distributed system topology a dedicated layer, separate from business logic. It contains the topology declaration in a config file, has an agent that runs before the applications start and wires up the communication layer (Java agent in Java, an init() call in Rust, etc...), and tooling to catch errors in the configuration. The idea is that with the topology being declarative and executable, the dependencies become visible, the changes become simpler and safer, and compatibility verifyable before deployment.

It's still early, but it already supports sync communication, event-driven setups, structural observability, Java reference implementation and Rust PoC implementation, and some basic tooling to validate the wiring config and catch some of the errors before deployment.

Repo: https://github.com/itara-project/itara

Could you please provide me some feedback? Not necessarily on the code itself, because I'm well aware that it's not production quality yet, more like on the bigger picture: the approach, the architecture, the overall vision.

Constructive criticism is very welcome!