Μην αγχώνερσαι, δεν είναι ανάγκη να πιάσεις τα πάντα. Από αυτό που περιγράφεις καταλαβαίνω ότι σε ενδιαφέρουν δύο πράγματα. Το ένα είναι το scalability, ήτοι η δυνατότητα κλιμάκωσης της λύσης σου, δηλαδή υποθέτουμε ότι μελλοντικά θα έχει περισσότερο "φόρτο", όποτε τη φτιάχνουμε από τώρα έτσι ώστε να μπορεί να ανταπεξέλθει αργότερα χωρίς re-engineering. Το δεύτερο είναι το high-availability, δηλαδή τα χαρακτηριστικά εκείνα που θα επιτρέψουν στο σύστημα να συνεχίσει να λειτουργεί όταν συμβούν διάφορα καταστροφικά περιστατικά. Και τα δύο υλοποιούνται με διάφορους τρόπους στον SQL Server, ωστόσο μια λύση με αυτά τα δύο χαρακτηριστικά δεν είναι αποκλειστικά θέμα του RDBMS. Για παράδειγμα, οι application servers είναι χαρακτηριστικό που εμπίπτει στο scalability. Μπορεί μπροστά να υπάρχουν δεκάδες ή εκατοντάδες clients οι οποίοι όμως μιλάνε και ανταλλάσουν data με τους application servers και όχι απευθείας με τη βάση. Δεν ξέρουν σε ποιά βάση τελικά συνδέονται γιατί ενδιάμεσα λειτουργεί/ούν ο/οι application server/ρs. H backup βάση των δύο βάσεων που αναφέρεις εμπίπτει στον τομέα του high availability.
Ως προς το scalability υπάρχουν διάφορες λύσεις. Μπορείς για παράδειγμα να υλοποιήσεις Distributed Partitioned Views έτσι ώστε να σπάσεις τα data σε πολλαπλές βάσεις, αυτό που στην ορολογία του SQL Server ονομάζεται Federated Database Design. Αυτή η λύση δεν απαιτεί να συντηρείς με κώδικα αυτόν τον διαχωρισμό, γίνεται διαφανώς για σένα από τον SQL Server. Αν στηρίξεις όλο αυτό σε ένα μηχανισμό clustering, τότε σε περίπτωση προβλήματος θα έχεις και το απαιτούμενο fail safety. Βέβαια, συνολικά, μια τέτοια λύση στον πραγματικό κόσμο έχει αρκετό κόστος καθώς απαιτεί high-end h/w εις διπλούν (ένα επιπρόσθετο node για κάθε federated server) καθώς επίσης και πολλαπλές άδειες SQL Server Enterprise. Ως εκ τούτου υπάρχουν διάφοροι εναλλακτικοί τρόποι για να πετύχεις αυτά που κουβεντιάζουμε, όπως το replication, το database mirroring, κλπ, ο καθένας με τα πλεονεκτήματα και τα μειονεκτήματα του.
Ως προς την εργασία σου, το ερώτημα είναι τι θέλει ο καθηγητής σου να υλοποιήσεις. Αν στηριχτείς σε έτοιμα features του SQL Server, ουσιαστικά δεν θα κάνεις ανάπτυξη παρά μόνο του s/w που θα πατάει πάνω σε αυτά καθώς όλα θα γίνονται από τον SQL Server. Πάντως όπως και να έχει, θα έπρεπε να γίνεται το ανάποδο. Να σου σώσει το σενάριο και να βρεις τη λύση βάσει των απαιτήσεων. Όχι να σε υποχρεώσει να υλοποιήσεις κάτι συγκεκριμένο και να ψάχνεις να βρεις σενάριο που να κολλάει σε αυτήν την ιδέα που έχει στο μυαλό του.
Vir prudens non contra ventum mingit