[happymellon]

My current situation is that I'm having to work with an event driven architecture for a strictly synchronous process.

Buzzword architecture is awful, and having Kafka offer fake design patterns to reassure naive architects, such as a request/reply with small response timeframes.

Attempting to replicate REST with overcomplicated overhead.

This is the biggest issues I encounter with event driven applications.

[somat]

pedantic note. nobody talking about REST really does REST. Where is the representational state. REST is when you ship the whole application in the message to the far side to let them figure it out.

Now that I've got that stupid pedantry off my chest, Yeah I know what you mean when you say REST we all know what is meant when REST is brought up. But I find it funny how Roy Fielding said "wow, it is really cool how web pages ship the whole application to the user on each request lets talk about that" and everyone else basically went "ok HTTP == REST, got it"

[happymellon]

On the one hand I could go

> Ah ha, but we don't use REST that's my complaint!

But you are correct, although I have used representational state through the request in this case I'm just talking about using a message bus Vs using a blocking http call.

Additional annoyance, using inappropriate tech means that we can't even do scaling to handle spikes. Having a Kafka rebalance because traffic is a little higher so I need to increase the number of listeners and cause an outage when I actually need more throughput makes me sad.

[inkyoto]

Hear, hear. A few years ago I worked for an esteemed client whose director said «I want Kafka» for [mostly] synchronous interaction patterns. I said «no», the director said «I want Kafka». That repeated a few more times, and I had to begrudgingly comply since the client was paying for it.

The architecture for the solution drew the inspiration pretty heavily from the TCP protocol design, with incoming events yielding either an ACK or a NACK events also dispatched asynchronously. The key was the stringent adherence to supplying the original event ID in the Reply-To event envelope (hello, SMTP) and having a separate process correlating the inbound and outbound ACK/NACK events. It has wrought success in times bygone (and does persist unto this present day), yet I must, with all due deference, decline to partake therein henceforth.

[geomagilles]

Indeed. Using a streaming platform makes sense only if you need messages durability (and sometimes reusability). When implementing a request/reply pattern on top of such a platform (Infinitic does that btw), it necessarily adds some latency due to multiple persistence operations.