We often use RabbitMQ like middle-ware, and it is boring because it has proven very reliable.
Most people that deal with <40k users a day will have low server concurrency loads, and can get away with database abstracted state-machine structures.
Distributed systems is hard to get right, and there are a few key areas one needs to design right...
If I was to give some guidance, than these tips should help:
1. user UUID to allow separable concurrent transactions with credential caching
2. global UTC time backed by GPS/RTC/NTP
3. client side application-layer load-balancing through Time-division multiplexing (can reduce peak loads by several orders of magnitude)
4. store, filter, and forward _meaningful_ data
5. peer-to-peer AMQP with role enforcement reduces the producer->consumer design to a single library. i.e. if done right the entire infrastructure becomes ridiculously simple, but if people YOLO it... failure is certain.
6. automatic route permission and credential management from other languages can require a bit of effort to sync up reliably. Essentially you end up writing a distributed user account management system in whatever ecosystem you are trying to bolt on. The client user login x509 certs can make this less laborious.
7. redacted
8. batched payload 128kB AMQP messages, as depending how the consumer is implemented this can help reduce hits to the APIs (some user UUID owns those 400 insertions for example.)
9. One might be able to just use Erlang/Elixir channels instead, and that simplifies the design further.
Most people that deal with <40k users a day will have low server concurrency loads, and can get away with database abstracted state-machine structures.
Distributed systems is hard to get right, and there are a few key areas one needs to design right...
If I was to give some guidance, than these tips should help:
1. user UUID to allow separable concurrent transactions with credential caching
2. global UTC time backed by GPS/RTC/NTP
3. client side application-layer load-balancing through Time-division multiplexing (can reduce peak loads by several orders of magnitude)
4. store, filter, and forward _meaningful_ data
5. peer-to-peer AMQP with role enforcement reduces the producer->consumer design to a single library. i.e. if done right the entire infrastructure becomes ridiculously simple, but if people YOLO it... failure is certain.
6. automatic route permission and credential management from other languages can require a bit of effort to sync up reliably. Essentially you end up writing a distributed user account management system in whatever ecosystem you are trying to bolt on. The client user login x509 certs can make this less laborious.
7. redacted
8. batched payload 128kB AMQP messages, as depending how the consumer is implemented this can help reduce hits to the APIs (some user UUID owns those 400 insertions for example.)
9. One might be able to just use Erlang/Elixir channels instead, and that simplifies the design further.
Have a great day, =3