Stack Exchange network consists of 183 Q&A communities including Stack Overflow, the largest, most trusted online community for developers to learn, share their knowledge, and build their careers.
@theyetiman That's because you will need to do some modification to enable it, it doesn't come out of the box so it's not documented. To understand what it's doing under the hood when you activate the configuration in xConnect the SQLProvider will automatically add an ApplicationIntent to the connectionstring received from the SMM db causing automatic distribution of read and write operations according to your setup failover group. I'll add some info to my response
@theyetiman the RefData Service has excellent caching but only in that particular role afaik meaning you are correct about a potential 200ms roundtrip for each call unless you have the service locally in each region. The RefData => DB might still be 200ms (unless you have those scalable reads setup) but thanks to the cache in the service the CD => RefData will almost never take that hit and pages are delayed minimally instead.
@theyetiman In regard to Scalable Reads and Auto Failover Groups I don't want to copy all documentation I referred to you. The walkthrough is here: doc.sitecore.com/en/developers/101/… to set this up from xConnect standpoint. It does use the read-scale out which is 1 region, multiple availability zones so if you want to go to Failover Groups you will need to do some manual configuration inside the ShardMap Manager database which should NOT be replicated and you need a plan to support failover
@theyetiman the fact that the Reference Data Service being down is enough for your CD to stop serving requests should indicate already what type of impact it can have. If you use any of the marketing functionality in Sitecore this service will come under significant usage. It also supports GeoIpData for example. So while Collection will be called 1 time at start and 1 time at end (which is even async so user won't notice) the Reference part can be used on every single page request.
I did a few quick tests on a clean 9.3 and I could have the custom file show up instead of YSOD on connectionstring error relatively quickly using: <system.webServer> <httpErrors errorMode="Custom" defaultResponseMode="File" existingResponse="Replace"> <remove statusCode="500" /> <error statusCode="500" path="500.htm" /> </httpErrors> </system.webServer>