Delay between adding user vs. availability in the API

Help
1

This issue was discussed previously here: Delay between registration and show user in list - #3

I would like to re-open this conversation, as to me this isn’t an acceptable answer. Many flows depend on a user being immediately available, so just saying that due to “indexing” this can be delayed (I’ve seen this take as much as 10 minutes, as described in the initial post) isn’t a sufficient answer.

Is the official position of Auth0 that the API shouldn’t be used for any timely operations? If so what’s the justification for such a position in a tool that is first and solely an integration tool, for a critical flow like user signup?

(Also I find it hilarious that Auth0 doesn’t use Auth0 for it’s own support forums, and instead I had to create a separate new account, with no options for any kind of federated login).

2

I think it’d be good to clarify which parts of the API can suffer from these delays: the Search APIs. That’s just the nature of search. You can’t look for something if it’s not indexed.

All other parts of the API, including the user endpoints, are immediately updated. Let’s say during user registration: if you receive the user profile after successful user creation, you can call the Get User by ID endpoint with the ID you just received and you will get a response.

Could you share a bit more about your use case, so the community can help you better?

4

Hi @benzittlau,

I wanted to reach out and let you know I will be looking into this, especially since the initial topic is quite old at this point. I hear your input and will be sure to come back with some answers.

In the mean time, can you please DM me the name of the tenant(s) where you are experiencing this behavior.

edit: Joao mentions the intended flow for user creation and search and has some insight on the topic:

Immediately consistent vs eventually consistent endpoints mentioned in the docs:

In addition to these things, we are always accepting feedback and you can open a conversation directly with the engineering team.

Thanks,
Dan

5

That’s just the nature of search. You can’t look for something if it’s not indexed.

I’d challenge the implication of that statement (that these kinds of delays are just inherent and unavoidable) from a technical standpoint. There are many different options of how to implement a search solution, and I don’t believe these kinds of delays are necessary using modern approaches to search. However, I don’t think whether it is technically possible to avoid these delays needs to be the centre of this conversation, so let’s table that for now.

Regarding the use case. There’s a few concerns I have:

  1. While it’s nice to believe that a 3rd party system will always work perfectly, I don’t assume that to be the case when I’m designing a reliable system involving 3rd party systems. Consequently there is an audit mechanism that checks the users added to Auth0 against our known users, to ensure that things are healthy. In theory I could implement this by doing individual API calls for each user while attempting to render a page, but at hundreds of users I imagine I’d hit your API throttles, and even without that my web servers or gateways would likely timeout. Instead I fetch users (matching given criteria), and use that to compare to our known users, flagging any issues in terms of incomplete or erroneous metadata, or straight out missing users.

  2. Our system functionally uses lists of users returned from this API for features. Having to explain to our users that that user they added won’t show up in features in the product until some indeterminate time passes isn’t an acceptable answer in my view.

Most of these issues arise as I don’t need a search API, I need a query API, but the search API is all you provide. (There’s actually no case in my usage currently that needs search, but several that need querying) I imagine it was a call on your end to make the Search API the “Get Users” API (note that it’s named Get Users and not Search Users), but only providing a Search API puts the burden of making that Search API performant enough to cover both search and query use cases on the implementation. I’d like to understand if this type of usage isn’t viewed as supported usage by Auth0, or if it is supported usage that’s just not meeting my expectations.

6

Hi there.
Just to clarify: what do you see as the difference between a search API and a query API? What are you querying/searching on?

There are many approaches to search, but the one used by Auth0 prioritizes quick response times for signups and logins while leaving indexing as an async operation that does not interrupt the login flow.

There are other extensibility points that might help with your use case, though. For example, we offer the pre and post user registration hooks (if you use database connections) that could be used to trigger a service request or database update for keeping track of new users.

Do understand that I’m just guessing here because I don’t know the use case in detail, but just to confirm:

  • user search depends on indexing that is eventually consistent
  • direct user access (/api/v2/users/{user_id}) and all authentication/authorization endpoints give immediate consistency.
7

HI Nicolas,
The distinction is specifically in response to:

My interpretation of that answer is “This is a search API, and search requires Indexing, so therefor this API will not be responsive to changes”.

Presumably this is referring to keyword based indexing for a system like elasticsearch or solr, as modern databases don’t incur significant delays re-indexing their data as rows are added or mutated. For example, when I add a new row to a database, I don’t need to wait for some backgrounded slow indexing to occur before I’m able to query against that data. I would be happy if you provide me the ability to query the data instead of using a search to perform a query. It appears that the implementation here is using a search system as the only way to query data; I am just inferring this from the statements I am hearing here, if this is not the case, and you’re not using a search system behind this API, I’d definitely be happy to have that assumption corrected.

Could you tell me what your SLO is on the delays for edits to show up in these systems? I have architected production scale search systems in the past, and while yes, there are often delays, we made the necessary investments to make sure that the user flow of: a) add something, b) search for it, could be supported by the performance of the system (this often meant an SLO of around 500 ms, from creation to addition to the search indexes). The fact that this operation is being backgrounded from the initial action is a separate conversation from that of the responsiveness your systems have been designed to support. Many backgrounding systems can pick up and process jobs within milliseconds of them being queued, and that’s not the scale of delay I’m complaining about here.

I think there are two paths this conversation could go down, and I’d prefer to figure out which one of those paths we’re going down:

  1. Are we discussing the fact that delays are inherent and unavoidable? That seemed to be the position initially put forward, to which I was arguing that’s probably because you’re using a search system, to respond to queries. Hence the query vs. search distinctions.
  2. Are we discussing the fact that that’s not what you’re doing, and that there is a query based mechanism here that doesn’t require heavy and expensive keyword search based indexing? Then I’m confused about why such large delays are being incurred.

Ben

8

Hi again Ben.

Actually, many databases work with an eventual consistency model as well. It’s a common design tradeoff. Auth0 chose this to ensure quick responses for the authentication pipeline. Note that we are not talking about a single backend database so the distinction between query and search becomes blurry. The /api/v2/users endpoint gives you a way to search/query many users at a time, with the caveat that there’s a delay in the results. There are several systems at play here to provide an extensible platform handling over 2 billion authentications per month.

I don’t think going down the path of discussing the technical limitations or design decisions would get us to any valuable outcome. But it is helpful to be aware of the limitations and design around that. To summarize:

  • results from GET /api/v2/users will give you eventually consistent results. There’s no SLO published for this. Auth0 tries to ensure these delays as short as possible, but your designs need to be aware of the eventual consistency.
  • GET /api/v2/users/{user-id} and GET /api/v2/users-by-email offer immediate consistency in their results.
  • there are other tools at your disposal, like custom DB scripts, rules and hooks that might help you with your use case.
1 Like
9

Hi Nicolas,
Could you please describe how I could utilize those suggested options to support the workflows described?

Actually, many databases work with an eventual consistency model as well. It’s a common design tradeoff

I agree with this 100%. It’s a design tradeoff informed by the system requirements. I expected that Auth0 was designed to be used as a federated user store, so that my use cases described above would be within the requirements for which your system has been designed (vs. a business intelligence system or a social networking site where eventual consistency doesn’t break the functional requirements of the system). I can’t remember integrating any system that’s shown such large latencies between object creation and availability on the list endpoint in the API, so I’m still confused why the design tradeoff’s were felt to be reasonable in this context. That’s great for you that you’re doing 2 billion interactions, but that does nothing for me as your customer. (Though I would hope that you could direct some of the revenue from all that usage to make this system more performant)

I don’t think going down the path of discussing the technical limitations or design decisions would get us to any valuable outcome.

It might not be a valuable outcome on your end, but as customer of your product understanding the use cases that you are designing your system to support, vs. the one’s that you don’t view as critical or supported, is very important and valuable to me. It’s actually more valuable than getting an understanding of this one tactical question, as knowing how you think about and invest into your product is more important to me than the current state of the product. For example, if the way this conversation went was “We agree that delays any longer than 1 minute are unacceptable, and have plans on our roadmap to ensure that in the future these delays will be managed.” Instead it appears Auth0 is unwilling to commit to any expectations, or communicate any additional information about what, as a customer who is using this for a core piece of my infrastructure, can expect in terms of performance guarantees from you, my vendor. That understanding for me, will be the most valuable outcome from this conversation (unless you are able to explain to me how I can resolve the use cases I described without incurring such delays using your system, but so far it seems that you’re describing features, but not putting them in the context of my requirements).

I agree that the technical limitations of your technology decisions shouldn’t be part of this conversation, but your team brought them in as justifications for the poor latency of this end point. I’d prefer to simply be told what the SLO’s are (and ideally make them reasonable), what are supported vs. unsupported intended usages of your product, and allow us to avoid any conversation about technical limitations of different options. Of course, working backwards from customer requirements to technical implementations that meet those requirements is what your engineering team is there for!

In the meantime, can you give any specification about this delay beyond “Auth0 tries to ensure these delays as short as possible”? I am embarrassed to communicate to my internal stakeholders, let alone our customers, that new users added, or changes to existing users, can take a completely unknown amount of time to show up or change. I’ve definitely seen this take over 10 minutes, and I communicated a case to Dan in DM earlier today that seemed to be pushing into the 30 min range IIRC.

Ben

10

BTW, if you had similar end points that supported batch requests (i.e. lists of ids or lists of emails), that would help significantly for my use cases (though still not be as ideal as a performant list endpoint with basic querying).

11

UPDATE: The 30 min example turned out to be a red herring. It wasn’t due to update delays in the API, but was due to confusion regarding nickname being an un-editable field. So the longest delays I’ve personally seen are in the ~10 min range.

12

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.