Here you should describe the funture situation. There is some LDAP that has the users, a Keycloak where clients can connect to to get their sessions keys/tokens, maybe a redis/postgres that has additional user information. that can be used for user statistics.

This is not nearly enough about iBet. I could not understand how it works.

What about User, Extended User, Chipcard, Customercard, Barcodes, etc. All this has to be supported in the end by your proposal. If have a new shiny system and we can not map it to the current iBet implementation then we have gained nothing.

this belongs to implementation

Definition

I think you should start with some sort of abstract, that states the problem.

.. currently users and permissions are scattered between multiple secondary servers. Because of this the users are only accessible via the ibet server. A consequence of this it is that it is hard to change or add new permissions or connect new clients because such an operations requires C++ code changes. Furthermore we most probably need to identify across different brands in the future for legal, statistical and other reasons. Therefor we need ....

add to definitions

What is a dc why is not definitions?

why is that? we need to handle automats as well without that we can just stop with this RFC because it will solve some problem but not ours.

without exposing data to each other

unique users that are vaild across services, to avoid that people need to register multiple accounts for different services

natural persons / unique real world agents

I am missing definitions like agents / units / devices here. We need to support more than people (natural persons) .

You should use correct wording like it is usually done in RFCs. I think you want a MUST here (is going to/will probably) is nothing for a RFC

https://datatracker.ietf.org/doc/html/rfc8259#section-1.1

Why has it to be centralized?

you design an implementaiton?

What does that mean?

Could you describe in a bit more detail what the underlying issue is? And how you intend to solve it?

• Do we have a timing / latency issue?
• Would the call to the new service be synchronous or not?
• Is it possible to have async code in the server without slowing other operations down?
• How are other things like risk evaluation impacted? (can we ensure that one user does not get processed on several service nodes concurrently allowing him to go over limits?)

Form my gut feeling the server is not async enough. I fear that we might need to improve the server first before we can use an external service that introduces even more latency. But that could turn out to be a major hard to do change.

Would it be more feasible to start with other parts that are read only like statistics (transactions can be re-executed and are not time critical) or a service that processes bet radar information (writing only - transactions are not expected to fail). Do not get me wrong I really like your idea but here we deal with a part that needs to read and write time critical information, which is probably the hardest part to get right. I would feel more comfortable if we could exercise with some easier part first.

What is the difference between an RMI that cancels and the cancel business metric? When and where is the cancellation technical and when is it more business related?

good page:)

I think we just need to increment atomic ints. That can probably be done lock-free.

I could image that I would want to configure the frequency for certain metrics to have a closer look.

I am not sure If we want to do that in iBet. I think it would be good to have the full data in the system that you eventually use for visualization. Therefor the aggregation in ibet does not help you too much and you have to transfer the 10 seconds data anyway.

I am missing some sort of motivation here?

We need to to store / collect data locally before sending it to a database because, creating network traffic for every single event is not cost efficient and we would spent too much time preparing and sending messages. Therefore we want only update xyz in discrete steps which make it possible to transfer the data into another system.

Maybe other servers could just send their data with a label to a DB as the primary could do. That way we do not need any complicated collection process and all servers are treated the same.

This is a good point and it gives us a good overview how many times something has been called and what the min/max/average time was.

GOOD!

They look like they cloud be mapped to handlers or aggregations of handlers.

should be solved externally - imo

What does that mean? Shouldn't we just pump all data in an external time series database?

I am not sure what that means, maybe you just delete that.

It should be in the long run, otherwise this is a waste of time.

I think we should have the some sort of status for this kind of document like proposal and accepted (tipster standard).

Do not make this document smaller in the first sentence than it actually is. Let's aim high.