0

Here are the design considerations for a software.

  1. The querying of data should be as fast as possible (reader <1s, writer <2.5s possibly since it also take time to reach the client end web or mobile)

  2. It should use microservices so there can be a swarm of them when load increases

  3. The system writes should be efficient and Sql Server should not become a bottleneck.

  4. Each mini-team should be responsible for their microservice only.

There is a common microservice (MS) design in which they expose a REST API and Web Gateway talks to them through their REST APIs. However I though of this design: AMQP based architecture

  • each microservice, there is a pair=> (reader, writer).
  • The writer would write to Sql Server and emits events
  • The cache updater listens to events and updates cache.
  • The reader would only query cache.
  • The gateway communicates only through AMQP either reader or writer

However I'm a bit confused if Web Gateway should be using AMQP to communicate to reader since it requires multiple hops

  1. Web gateway to AMQP (Query)
  2. AMQP to Reader (Query delivered)
  3. Reader to Cache
  4. Cache to Reader
  5. Reader to AMQP (Response)
  6. AMQP to Web Gateway (Response delivered)

Would it be a better idea NOT TO USE AMQP for readers? Other choices could be

  1. gRPC
  2. rsocket
  3. NETMQ, a dotnet variant of ZeroMQ: fastest but it involves checking your each frame yourself

Does this design not satisfy the objective 4 that each team should work on their microservice only? If I put reader and writer in one service then it increases the surface area as reader would be communicating through a mechanism other than AMQP for performance while writer is using AMQP.

2

I will share a few of my thoughts but please take my word lightly.

Microservise's size

A microservice can be as big as it needs to be. I remember reading about the pizza rule once, which said that a microservice should be that big so it can be maintained by a team which can be feed with two pizzas. That said, I would not worry about increasing this service's surface. Another motivation to decouple reader and writer can be found in the CQRS pattern.

Number of hops

To your second question, whether gRpc, rsocket or NETMQ are better variants for your design, I think the hops will remain the same, in different layers maybe but still the same. What you could do is have the reader reply to the web directly without the gateway's interference. This should be a solid design.

Performance

Now which of these 4 solutions will have a better throughput(performance) in your scenarios, I am afraid I do not know. However, I would presume the difference should be somewhat negligible in your scenarios, which you have not shared..:P Have a look at these resources: Messaging vs RPC in a distributed system and RSocket vs. gRPC Benchmark

Alternatives

Then again, vertical scaling as you mentioned your readers can always be a solution, together with prefetching the cache content inside the readers, if needed, or coupling readers and cache, providing an interface for anyone interested, gateway included.

|improve this answer|||||
  • it gives me some ideas but I could not understand reader reply to the web directly. do you mean that the response by-passes gateway or the reader should not be behind gateway? the reader communicates to cache using pure sockets. – Simple Fellow Nov 2 '19 at 15:09
  • Yes, my purpose was to give you some ideas, as you only can decide the trade offs that suit you best ! And yes, I mean the reader can inform the web directly via sockets for example. It can still be behind the gateway, which will receive the request pass it to the reader, but the readers response does not need to go through the gateway again but to the concerned client directly ! – Cap Baracudas Nov 2 '19 at 15:33
0

The querying of data should be as fast as possible (reader <1s, writer <2.5s possibly since it also take time to reach the client end web or mobile)
Fast querying of data is related to how your database is structured and how your query is constructed. For instance, you can have your DB completely normalised, but that will affect the performance of writes when trying to update multiple tables at once. Since your reads are directly from a cache, you will most likely get a latency of less than 1s (I don't know the scale or the size of data, but this is achievable)

The system writes should be efficient and Sql Server should not become a bottleneck.
Sql Server being a bottleneck will depend again on number of queries/second, configuration of Sql Server, provisioning of resources both at server(CPU/Mem) and client(Connections, parallel request limit). Special Note: lot of indexes can hit your query time too, beware.

The cache updater listens to events and updates cache.
A few things to consider:
1. How consistent do you want the cache to be in comparison to your DB.
2. How critical is the data, what happens if your lose events and cache is not updated?
3. How do you handle cache failure situations? Do you populate the data from DB again?

If there is no strong requirement, I would prefer having a single and consistent mechanism for loading and updating cache. With this, the event listener would not really be required, you can have a scheduled cache load/update.

The gateway communicates only through AMQP either reader or writer gRPC and RSocket lie at different levels in osi, not exactly apple-to-apple comparison. As long as the client-server communication is non-blocking, (based on reactive programming or even RSocket), you might not require AMQP.

[Edit]
Came across this: https://github.com/salesforce/reactive-grpc Reactive Stream with GRPC.
I would suggest you benchmark this for your requirement. If you can crack this, you will derive the best of both worlds.

|improve this answer|||||
  • thanks a lot for answering, reactive stream is surely a good idea however I have the constraint of dotnet core 2.2 – Simple Fellow Nov 2 '19 at 15:06

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.