In SharePoint 2013 Search, we have Content Sources and Result Sources.
We have Result Sources, Result Types, Result Blocks and Result Sets.
Not to mention Query Rules and Query Builder that one can see everywhere, but defining them is not easy at all. Looks like Query Rules are the "fresh air" of Search in 2013. We feel it, we need it, but hard to touch it...
This is why I decided to create a "big picture" of SharePoint 2013 Search. I'd like to emphasis that it's complex but its beauty is in this complexity: there're so much you can build with Search!
Well, what you can see on this "big picture"?
On the left side, there're the source systems, with all the data you can "pull in" to SharePoint Search. The most important types of data sources are SharePoint sites (of course), file shares and database content (through direct DB access or Web Services), but you can also connect to Exchange Public folders and web sites (for example, your company's public website). If you have some very specific system, you can also write or buy a 3rd party custom connector (for example, to SAP).
You can connect these systems by creating Content Sources in SharePoint. I wrote a blog post on "How to Organize Content Sources" a while ago, you can find some best practices there.
The process, in which the Search Engine enumerates and gets the content from these systems in called Crawling. The crawled items will be then indexed into the Local Search Index.
Based on the local index, we can create Result Sources. They can get the indexed items from one or more Content Sources, and we can also apply some filters there. For example, a Result Source can be "Documents" from "everywhere", or "Old content" including everything that is older than 3 years.
The other way to pull in content into SharePoint Search is Federation: you can define Result Sources to use a remote index to provide the results from. With this, you can provide results from huge web sites like MSDN or Financial Times, or from places that use different security options, etc. You don't have to build the index as you use it from a remote location, but you need live Internet connection, and there're some other limitations too.
Besides the "content" itself, we store a lot of metadata in the Local Search Index, and they are used in a lot of different way. For example, they'll be the basics for the Refiners, we can Sort the results by them, we can display them on the Result Set and/or on the Hover Panel, etc. Don't forget: metadata is the "glue" of Search, and despite it's a relatively small part of the picture above, this might be one of the most important things in the full Search story!
Query Rules are in the middle, because as I said, there're everywhere. You can use them to transform a query, to change the ranking of the results, to display various Result Blocks (oops, one more Search term here!), etc.
Result Sets are basically where we display the results in. They can use Query Rules in as well as various Result Sources. They can also display various metadata (managed properties) from the Local Search Index.
They also use Result Types to decide which item should get displayed in what way (for example, a Word document will be displayed differently than a Calendar item).
Hover Panel gets displayed when the user hovers the mouse over a result in the Result Set. Hovel Panel is the flyout card with the document preview (if it's available), with some metadata , and with some actions to take on the results (for example, open the document, open its location, send it to someone, start a workflow, etc.) Again, Hover Panel is tied to Result Types - different types have different Hover Panels.
If it's all together, the results are ready to get displayed - the last question we have left is how. The answer is formulated in Display Templates. They define the way the results have to get displayed (by Result Type, of course) as well as how the Hover Panel will be displayed. Moreover, we use Display Templates for the Refinement Panel as well.
Long story short, this is the "big picture" of Search in SharePoint 2013. Of course, each of these pieces would worth a separate blog post or sometimes even a separate book (like Query Rules, for example). Hope this helps you to understand how these pieces work together - please let me know if it makes sense, if I should change or add anything. This is still evolving.