Unless you are doing something like a high-frequency trading system, or an automated manufacturing architecture where 1-5ms latency might mean broken materials (or machines) then Elixir will serve you just fine.
But to be able to answer properly you should tell us: how much load do you expect? Is the latency critical and how much (with what timing tolerance)? What’s your general intended use-case?
With practice during the last ~3.8 years I found that people very often underestimate Elixir, to their future peril. The runtime can do a lot. Not to mention that the diagram you so nicely provided would be months of work with many other runtimes. With the BEAM, that diagram is possible after 1-2 weeks of work prototyping the OTP app(s) / supervisors / workers structure – then the runtime just makes it happen.
One example for bad tech choice when near-realtime is required are the people who regularly pick Golang only to be bitten hard by its growing GC pauses as the load and memory usage grows; Golang’s GC prefers to slack off and delay work for the future which works perfectly in a lot of apps because they don’t have constant memory pressure. But the people who are after near-realtime systems usually are in for a rough wakeup call because the GC pauses just grow and grow until your system starts missing messages and some responses start taking seconds to finish.
Such people would have been better off picking D or Rust and just get some elbow grease.
So, depending on what you’re after, Elixir might be perfect (because it allows for your architecture and will take you there very quickly in terms of dev iterations) but it could also be awful (if you are after 1 microsecond latency or less – mind you, it could provide that but it doesn’t guarantee it).
EDIT: Just read the diagram in more details. You are saying you are after 50ms or less. This is very doable in the BEAM but it will depend a lot on the I/O stack and memory controller of your hardware. Using GenStage / Flow / Broadway you can be applying back-pressure to the producers of data and tune your system for maximum throughput while still having <50ms response time. That however would require you to invest in telemetry in your code – and a backing time-series database so you could make your own statistics.