4

I haven't done extensive unit testing in java script. But the principles remain fairly same in all the languages. Properties of a good unit test would be Runs quickly and provides nearly immediate feedback Doesn't have side effects, like charging a credit card, or modifying a database or event publishing an event What needs to be tested in your case Is ...


4

Ideally, you don’t. This sort of approach is fraught with partial failure scenarios. What happens if B and C process, but D dies irrecocably? What happens when you get duplicate data from any of the workers? In general, you get a new service E which listens for results from BCD, writing the partial results to its own db. Potentially it could be a part of A -...


3

With an 'E' B, C, and D each publish their own completion event. E subscribes to those new events, collecting information from each and storing its state until it recognizes that it has received all the events, potentially in any order. Once it has received them all, it completes its own processing with all the information it needs, possibly publishing its ...


2

The very point of asynchronous systems such as Kafka is that you gain performance in exchange for some kind of guarantees - in your case the guarantee for in-order processing. Forcing one event to wait for another pretty much removes the benefits Kafka offers to you - if you want to go that way, better use a queueing system instead of an asynchronous one ...


2

I believe Kafka has the notion of "Partitions". If you put messages in the same partition they will be processed in order by a single processor "By having a notion of parallelism—the partition—within the topics, Kafka is able to provide both ordering guarantees and load balancing over a pool of consumer processes. This is achieved by assigning the ...


1

For your scenario, an enterprise service bus like Azure Service Bus is better suited as they are designed specifically for it. Because of this, you can benefit from several features like retries, automatic deadlettering, transactional sends with receive, automatic deduplication, etc. Event streams are most suited for scenarios with huge amounts of events (...


1

As SoftwareArchitect123 said, we don't have enough context to say if you should or you shouldn't use Kafka as a solution. I've worked the last year or so pulling in Kafka as a new tech, so I can anecdotally compare them a little bit. Unless your are handling very large load (billions of records), I would not recommend pulling Kafka in as a new tech (if it ...


1

Due to the limited information available, no clear answer can be given here, but instead of questioning the use of Apache Kafka, it could be useful to search for well-known alternatives. In such discussions, RabbitMQ is often mentioned as a possible option. The difference between these two technologies has already been extensively debated in Is there any ...


1

A few things to consider in your architecture: separate the entry point in the system from my service implementation It depends if you want to expose capabilities of your services and create api gateway or you just want to replace direct communication with messages, increasing availability and decrease latency of your system. Think twice if you will ...


1

Are B, C, D real microservices or just functions? If they create meaningful result (e.g. OrderCreated, InvoiceCreated, BillDelivered) in their context I think you should save events created by each of them separately to not block and wait for the slowest. You can than move logic which combine them to event processor and execute only if needed. Although if ...


1

gRPC and queues|brokers are not mutually exclusive. It's not like we have to choose one or another. We might choose one, both or none. We could also use an SMTP server as a queue, or a plain text file. They can complement each other since they satisfy different purposes. Decoupling Think in a pipeline where each stage is a process (service). [Process A]...


1

gRPC can do asynchronous requests, but it is still an RPC pattern and so that is mostly for when you don't care about the answer, not for implementing message (sub/pub) systems. What I do is, if I need RPC I use gRPC for the communication and ProtocolBuffers to serialize the data, and then when I need messaging I use AMQP, also with ProtocolBuffers. It ...


Only top voted, non community-wiki answers of a minimum length are eligible