Hi,

The basics of this kind of setup are described in this article but the specifics will depend on your hosting/infrastructure setup:
https://docs.developers.optimizely.com/content-management-system/docs/decoupled-setup

In Optimizely CMS, the user interface is part of the deployed CMS site and all instances of the site point to the same database. This means your deployed codebase will be the same for both the public-facing site and the CMS UI but with some differences in the configuration to block access to the UI from the public-facing sites. In situations like this where the UI should only be accessible via a separated back-end server, I'd suggest configuring the front-end servers to return a 404 status when the UI URL is requested rather than a 401/403.

As an alternative approach, you could go for a headless configuration where the content is edited in the CMS and published either via REST APIs or by Optimizely Graph. In that scenario you can still configure on-page editing in the CMS but the public-facing site would be entirely separated from the CMS.

Thank you Paul. That was very helpful. Appreciated

1 question I have is about the database, can we use separate databases for CMS and website. Can we use a primary database for CMS and replicated database for websites ?

Regarding website scaling, I know Optimizely CMS have some internal content caching, do we have a cache eviction mechanism based on save & publish event ?

I'll pick up the cache eviction question first as that feeds into the answer for the DB question. Optimizely CMS is pretty effective at caching content and the internal caching mechanisms will invalidate the entry for a given content item when that item is changed (e.g. a new version is published, the item gets deleted / expired, etc.). This is all tied to a remote events system which will perform a distributed invalidation of the cache across all instances in a load-balanced environment so, assuming it's all set up correctly, updated content should appear pretty much immediately on all servers.

Now to the database question. I'm afraid the basic answer is that you should have a single database which is used for both the CMS and public-facing sites. There are ways you could make it work with replicas for the public-facing sites but you may run into a few issues. The distributed events run pretty much immediately but the database replication doesn't so you can end up with older versions of the content being served from the cache because the cache is rebuilt before the DB has updated. I wrote about that issue and a potential workaround back in 2018. I've not revisited it so it may be a bit out of date but it might help:
https://world.optimizely.com/blogs/paul-gruffydd/dates/2018/10/going-global--geographically-scaling-an-episerver-site-over-multiple-azure-regions/ 

Thank you Paul