Welcome to the JavaRanch, Sushant!
In a nutshell, JSF works as a Movel/View/Controller framework, where the master Controller is the FacesServlet, the Views are defined as template files (.xhtml in JSF2), and the Models are user-designed POJOs. Every JSF request is routed into the FacesServlet, which determines which View it will render, thereby determining what Model(s) the View will require. Model objects that do not already exist are automatically manufactured under direction of the FacesServlet and placed into their specified context. There are finer points to the process, but that's the architectural framework.
The actual JSF logical lifecycle is well-documented. Point your web search tool of choice to "JSF Lifecycle" and you'll probably be rewarded with a number of pages that display the block diagram of the JSF lifecycle. It hasn't changed notably since JSF was first created.
The FacesServlet creates and maintains compiled versions of the View Templates as data structures called Component Trees. The Component Tree contains information about how to render the View and anchors input data. The net effect is that you can author complex web applications with validated forms by writing View Templates and POJO UI Model objects (backing beans), and the Controllers are already pre-supplied. In fact, excluding the DataModel and SelectItem objects, most well-designed JSF apps have almost no JSF-specific code in them. JSF works from the outside, using the Inversion of Control (IoC) design
pattern.
Those are the high points. My reference for details has been Kito Mann's "JavaServer Faces in Action" (Manning Press), although my copy is quite old now.