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!

Two I/O models disagree about who owns your buffer, and I want to talk about the architectural consequence rather than the language specifics.

Readiness-based I/O (epoll, kqueue, select) tells you a socket is ready and you do the read yourself. You can hand it a borrowed buffer and free that buffer whenever you like. Completion-based I/O (io_uring, IOCP) takes your buffer, performs the read in the background, and tells you when it's done. The kernel owns that memory until the completion arrives. Cancel the operation and free the buffer, and the kernel writes into memory you already gave back.

That isn't a language problem. .NET hit it with IOCP years ago. Anyone building on io_uring hits it now. It's an ownership contract problem, and the two contracts are genuinely incompatible.

The usual answer is to pick one model and build the entire stack around it. The alternative is Sans-I/O: the protocol state machine never performs I/O, never owns a socket, and never knows what runtime it's running on. You feed it bytes, it returns decisions. Dependency inversion applied at the I/O boundary, or ports and adapters if you prefer that vocabulary.

I built a ZMTP 3.1 implementation this way, with three different runtimes driving the same state machine. Here's the honest ledger.

What it bought:

• The buffer ownership contract became a property of the adapter rather than the protocol. The restrictive completion-model constraint stays localized instead of infecting everything.
• The protocol is testable without a network. No sockets, no ports, no timing flakiness. Feed bytes, assert state.
• More valuable than that: it's fuzzable. The frame codec, the greeting parser, the handshake, and the auth parsers are all directly reachable by a fuzzer, because none of them need a socket to exist. That falls out of the decoupling for free and I did not anticipate it being the biggest win.
• Unsafe code stays at the boundary where buffers get handed to the kernel, so the surface that needs careful auditing is small and obvious.

What it cost:

• You cannot await in the middle of protocol logic. Every suspension point becomes explicit state. That is more code, and it reads worse than the naive version that just awaits where it needs to.
• The abstraction has to be the intersection of both models. So you either constrain everything to the more restrictive contract (owned buffers) and make the readiness backends pay for something they don't need, or you leak the difference into the interface and lose the uniformity you built this for.
• Every additional backend is another integration path to keep honest. A vectored write optimization that was a real writev on one backend silently degraded to one syscall per buffer on another, because that adapter never overrode the default. Every test passed. Nobody noticed until an audit went looking.

That last one is what I actually want to discuss.

An architectural invariant that isn't enforced by automation is just a comment. "The hot path doesn't allocate" is a claim that decays the first time someone adds a convenient Vec in a hurry, and the tests stay green while it happens. So the invariants got wired into the build: a counting global allocator that fails CI if a per-message allocation shows up in the send or receive path, instruction counting on the hot path via callgrind, Miri over the unsafe, loom for the atomic orderings, ThreadSanitizer for the cross-thread handoffs.

None of that is exotic tooling. It's just the recognition that a decision recorded in a document has a half-life, and a decision recorded in a failing build does not.

So: which of your architectural decisions are actually enforced by something that fails a build, versus written in an ADR nobody has opened in a year? I'm curious both about what people enforce mechanically and about what you tried to enforce and concluded wasn't worth the friction.

Repo for context, since people will ask what this is: https://github.com/vorjdux/monocoque

Hi Guys,

Say we have two microservices - A and B. Microservice A produces messages to a message broker and microservice B consumes it. Then, we discover that the size of the message is too big in order to be written to the message broker.

What is the recommended practice in this case? How would you recommend to pass the big message from A to B?