Adaptive Testing Platform: IRT-based assessments for about 89,000 students

Mahdi Molavi October 4, 2026 4 min read

Since October 2023 I have been a senior backend engineer at NovaTech, a company based in Tehran, working remotely. There I architected an adaptive testing platform that uses item response theory (IRT) for personalized assessments and analytics. It serves about 89,000 students, and I lead .NET 6/8 microservices development.

Context

A fixed exam gives every student the same questions. That is easy to run but inefficient. Strong students spend time on items that tell you nothing new about them, and weaker students face a run of questions they have little chance of answering. Adaptive testing changes this by choosing each next question based on how the student has answered so far.

The platform covers four parts of an assessment's life: creating it, selecting items for each student, scoring the responses and reporting the results.

The engineering problem

IRT models the chance that a student answers an item correctly as a function of two things: the student's ability and the item's own parameters, such as its difficulty. Once items are calibrated, ability can be estimated from different sets of items and still land on the same scale. That property is what makes adaptive selection possible.

It also makes the backend harder than a normal quiz engine. In general terms, an adaptive testing system has to deal with four things at once:

State changes on every answer. After each response the ability estimate moves, and the next item depends on it. Selection sits directly on the student's path, so it has to be fast and correct every time.
Exam traffic is bursty. Students tend to start together and finish close to a deadline. Load that is quiet for most of the week can arrive within minutes.
Scores have to be explainable. If a result is questioned, you need to show which items were served, what was answered and how the score followed from it. That favors careful storage of responses over clever shortcuts.
Analytics read the same data. Reports want to aggregate across many students, ideally without slowing down the students who are still taking a test.

What I built

I architected the platform and its IRT-based approach to personalized assessment and analytics. I built the workflows it runs on:

Assessment creation, for setting up assessments and their items.
Item selection, which picks the next item for each student.
Scoring, which turns responses into results.
Reporting, which turns scored data into reports and analytics.

These workflows hold up during peak exam periods.

Alongside the architecture work, I lead .NET 6/8 microservices development. I mentor 5+ developers and set the review standards for high-traffic features. Those standards matter most on hot paths: a small inefficiency in code that runs on every request gets multiplied many times over during an exam.

Design notes

The reasoning below is general. It explains the approach; it is not a map of NovaTech's internals.

Why IRT

Classical scoring counts correct answers, so the score depends on which test a student happened to get. IRT puts students and items on one scale, which is why two students who saw different questions can still receive comparable results. Adaptive testing depends on exactly that. A common selection rule is to serve the item that is most informative at the student's current ability estimate, within practical limits such as covering the required content and not overusing the same items.

Why microservices, and what they cost

In an assessment system, the parts have very different load patterns. Authoring is light and steady. Selection and scoring spike during exams. Reporting is read-heavy and can often tolerate a short delay. Microservices let parts with different loads scale and deploy independently.

The cost is coordination. Services need clear contracts, and any data that crosses a service boundary needs a single owner. Code review is where much of that discipline is enforced, so review standards for high-traffic features are part of the architecture, not a team formality.

Storage and caching

The stack pairs SQL Server, accessed through EF Core, with Redis. In a system of this kind, the relational database is normally the source of truth for anything that affects a score, because it gives transactions and a durable record. An in-memory store such as Redis usually holds data that is read far more often than it changes, so the database is not asked for the same values again and again during a peak. The trade-off is that every cached value needs a clear rule for when it expires or is refreshed.

Stack

.NET 8 and .NET 6, as microservices
EF Core
SQL Server
Redis
Docker
Python

Outcome

An IRT-based adaptive testing platform that serves about 89,000 students.
Assessment creation, scoring, reporting and item-selection workflows that hold up during peak exam periods.

Exam peaks are also the subject of the Redis Sentinel case study from my earlier work at Gozine2. If you are planning an assessment or high-traffic .NET system, see Work with me.

Frequently asked questions

What did Mahdi Molavi build at NovaTech?

He architected an adaptive testing platform that uses item response theory (IRT) for personalized assessments and analytics. It serves about 89,000 students.

Which technologies does the adaptive testing platform use?

The stack is .NET 8 and .NET 6 microservices with EF Core, SQL Server, Redis, Docker and Python.

What is his role on the team?

Since October 2023 he has led .NET 6/8 microservices development, mentored 5+ developers and set review standards for high-traffic features.

More in this section

Projects