Architecture Interview Questions

A backend developer builds the parts of an application that users never see: the database, the business rules, and the APIs that apps call. They are responsible for data being correct, safe, and fast. In a School Management System, that means the attendance tables, the rule that marks cannot exceed the maximum, and the API the mobile app uses.

The frontend is what users see and click: a website or mobile app running on their device. The backend runs on a server: it stores data, applies business rules, and exposes APIs. The frontend never touches the database; it calls the backend over HTTP.

Data outlives applications: screens and services get rewritten, but school records stay for years. The tables decide what the code can do, and changing a table after real data exists means migrating that data. Designing the data model early also exposes missing requirements, such as a student having two guardians, before any code depends on them.

A production-ready system enforces its rules on the server and in the database, not only on the screen. It handles two users saving at once, records who changed what, restricts data by role, logs errors, has tests, and stays fast with realistic data volumes. A tutorial usually shows only the happy path with ten rows.

Split it by business capability: masters (years, classes, sections, subjects), students and guardians, enrollment, attendance, exams and marks, fees, users and roles, and a dashboard. Each module owns its tables and endpoints. Note the dependencies: attendance, marks, and fees all depend on enrollment, so masters and enrollment are built first.

In all three, for different reasons. The screen validates for quick feedback, the API validates every request because any client can call it directly, and the database constraints are the last safety net. For example, "marks cannot exceed 100" is shown on the screen, rejected by the API with 400, and blocked again by the database.

Measure each layer instead of guessing. The browser's network tab shows how long the API call took; the API logs show how much of that was the database call; the database's execution plan shows why the query is slow. The usual causes are a missing index, a query returning far more rows than the screen needs, or many small queries in a loop.

The database credentials would have to live on every user's device, where anyone can extract them. There would be no single place to apply business rules and permissions, and every app would break whenever a table changes. An API keeps the database private, applies the rules once for every client, and gives apps a stable contract.

A functional requirement describes what the system does, such as "a teacher marks daily attendance". A non-functional requirement describes how well it does it: speed, security, reliability, such as "the class list loads in under 2 seconds". Both must be written down and testable.

A user story is a short requirement written from the user's point of view: "As a [role], I want [action], so that [benefit]". For example: "As a class teacher, I want to mark attendance for my whole section in one screen, so that I finish it in five minutes." It is completed with acceptance criteria that define when it is done.

A role is a type of user with its own permissions, such as Teacher, Accountant, or Parent. Listing roles shows who uses each feature and what each must not be allowed to do. Roles later become rows in a Roles table and permission checks in the API.

Acceptance criteria are the checks that prove a story is done. A common format is Given / When / Then: given a starting situation, when the user acts, then a specific result happens. Each criterion should be testable, for example "given attendance for 10-A is already saved today, when the teacher saves again, then records are updated, not duplicated".

The important nouns become tables (Student, Section, Exam), and their details become columns. Rules become constraints, such as a unique admission number or marks within the maximum. Relationships become foreign keys or junction tables, for example a student with two guardians. Non-functional requirements shape the design too, such as soft delete and audit columns.

Compare everything that can differ: tool and runtime versions, configuration and connection strings, environment variables, database data and schema, and permissions. Read the server's logs for the exact error, then reproduce it locally with the same settings. Most cases come down to a version or configuration difference.

Single Responsibility, Open/Closed, Liskov Substitution, Interface Segregation, and Dependency Inversion: five principles that keep object-oriented code easy to change as it grows.

A class should have one reason to change. In the SMS, FeeNotice decides the wording and an INotificationSender decides the delivery channel, so a wording change and a provider change each touch one class.

An object that stores and finds entities so the rest of the code never deals with SQL, such as IStudentRepository with GetByAdmissionNumber and Add. Its interface lives with the business rules; implementations live in the data layer.

Code should be open for extension and closed for modification: add behavior by writing new classes behind an existing abstraction, not by editing tested code. A new notification channel is a new INotificationSender; the Notify method never changes.

A derived class must work wherever its base class is expected, keeping the base class's promises. A ReportCard subclass whose FormatScore throws NotSupportedException compiles, but breaks any code holding a ReportCard.

Dependency inversion is a design principle: high-level rules depend on abstractions they own, not on low-level details. Dependency injection is a technique: dependencies are passed in from outside, such as through a constructor. A DI container automates the injection.

Introduce or use a repository interface, have the service receive it through its constructor, and create the concrete repository in one composition root. The offline version becomes a new class implementing the interface, and the service can be tested with an in-memory fake.

The single place, usually at application startup, where concrete implementations are chosen and wired together, such as new StudentService(new InMemoryStudentRepository()). The rest of the code depends only on abstractions; in ASP.NET Core, Program.cs with the DI container plays this role.

When principles are applied without a real cost to remove: interfaces with one implementation and no tests, factories for simple objects, layers that only pass calls through. Apply a principle when you can name the change or test it makes easier; keep pure, stable code simple, like a static rules class.

A named, proven solution to a recurring design problem, described as a shape of code rather than a library. Names such as Factory or Decorator let developers communicate a whole design in a word.

A method or class whose job is to decide which object to create, so the decision lives in one place. NotificationSenderFactory.For(guardian) returns an email or phone sender; callers never write new EmailSender() themselves.

A family of interchangeable rules behind one interface, chosen at run time. IGradeScale has a primary-band strategy and an A1-to-E strategy; the report code uses whichever it is given.

A class that implements an interface and wraps another object of the same interface, adding behavior before or after passing calls on, like LoggingSender. ASP.NET Core middleware, stream wrappers, and retry or caching layers follow the same idea.

A subject notifies many observers when something happens, without knowing them. C# events implement it directly: FeeInvoice.PaymentRecorded notifies every subscriber after a payment.

Any code can reach it through a static property, so dependencies are hidden; tests cannot replace it; and its shared state must be thread-safe. Registering the class as a singleton service with dependency injection keeps one instance while making it explicit and replaceable.

Use decorators: a retrying wrapper and a logging wrapper around the unchanged provider, all implementing the same interface. Each concern stays separate and testable, and any future provider gets both by being wrapped the same way.

When it removes no real cost: a factory that always returns one class, a strategy interface with one implementation and no plan for more, decorators no one needs. Apply a pattern when you can name the repeated decision, changing rule, or extension it supports.

Dependency injection (replacing factories and singletons), decorators in the middleware pipeline, strategies for logging and configuration providers, and options and observers for configuration changes. Applications should depend on interfaces, register implementations in one place, and add cross-cutting concerns as middleware or decorators.

An interface between business code and data access. The service asks the repository for entities, such as GetByAdmissionNumberAsync, and never sees SQL, connections, or the ORM. Implementations can use ADO.NET, Dapper, EF Core, or memory without the service changing.

A host layer (console or Web API) that starts the app and wires implementations, a core layer with entities, rules, services, and interfaces, and a data layer with the database code. Host and Data reference Core; Core references neither, so the rules depend on nothing that changes often.

The single place where concrete implementations are chosen and connected to the interfaces that use them. In SchoolApp's console it is Program.cs; in an ASP.NET Core app it is the dependency injection registration at startup. Everywhere else, code receives interfaces through constructors.

The high-level core project defines the interface it needs, IStudentRepository, and the low-level data project implements it. The compile-time dependency points from Data to Core, the opposite of the call direction, so the rules never depend on database details.

A unit of work collects several changes and saves them together in one transaction, or not at all. A DbContext already is one: it tracks changes and SaveChangesAsync writes them atomically. With ADO.NET or Dapper you build it yourself, sharing one connection and transaction across operations.

Callers would then compose queries, so database concerns, such as what can be translated to SQL and when the query runs, leak into the service layer, and the repository can no longer be swapped or faked faithfully. Return finished results: entities, DTOs, or pages.

It mostly duplicates DbSet<T>, offers methods nobody should call, such as GetAll on 10,000 students, and often leaks IQueryable. Specific repositories with methods named after real needs, or the DbContext directly in simple apps, give the same isolation with clearer intent.

In SchoolApp, a rolled-back transaction removed a new student from SQL Server, but the in-memory repository kept it, because a dictionary does not take part in transactions. Unique constraints, case rules, and generated values can differ too. Keep fast unit tests on fakes for rules, and run integration tests against the real database for behaviour that depends on it.

In small apps with few rules, a stable data-access choice, and tests that can use a real database, a repository adds files without removing a cost; the DbContext can be used directly. Add repositories where rules need protecting, data access may change, or tests need fakes, and keep the decision reversible by keeping database code out of the core.