A registration platform lets students search the course catalogue, checks that they may take what they choose, and records their enrolment against a limited number of places. In many universities it is a module of a student information system that also holds admissions, grades, fees and timetables, built around one relational database and extended over many years by local customisation. The architecture is the classic monolith: one deployable unit, one schema, one release cycle.

Microservices divide such a system into small services that are deployed independently, own their data and communicate over the network (Lewis and Fowler, 2014; Newman, 2015). The style grew out of service-oriented architecture and the operating practices of large web companies (Dragoni et al., 2017), and it promises exactly what registration seems to need: the ability to scale the part under pressure without scaling everything, and to change one function without redeploying the rest.

Whether the promise holds for a university is less obvious. The sector has small development teams, fixed academic calendars and strict duties towards student data. This review asks what the published literature on monolith-to-microservice migration teaches, and how far those lessons carry over to a registration platform.

The article is a narrative review. It considers peer-reviewed studies of microservice migration, notably interview and survey research with practitioners, published experience reports, a systematic review of grey literature, and the books that practitioners themselves cite. It does not report a migration carried out by the author and describes no particular institution. Published accounts that deal specifically with university registration are scarce, and that scarcity is itself a finding. The general literature is therefore read with the registration domain in mind, and the reasoning that connects the two is made explicit so that readers can judge it.

Three properties of the domain shape any architectural decision. The first is the load profile. Demand is concentrated in short windows at the start of each enrolment period, when a large part of the student body arrives at the same minute and competes for the same popular sections. The second is a hard invariant: a section has a capacity, and the number of students enrolled must not exceed it. Prerequisites, timetable clashes, credit limits and holds on a student's account are further rules that must be evaluated at the moment of enrolment, and they draw on data owned by other parts of the system.

The third property is regulatory. Student records are protected by law, in the United States by the Family Educational Rights and Privacy Act (FERPA, 1974) and in the European Union by the General Data Protection Regulation (European Union, 2016). An architecture that copies student data into many service databases multiplies the places where access must be controlled, audited and, where the law requires, erased or corrected.

Practitioners interviewed by Taibi et al. (2017) named maintainability and scalability as their main reasons for moving to microservices, and admitted that some migrations were undertaken because others were doing the same. The industrial survey of Di Francesco et al. (2018) found a similar mix of technical and organisational motives. The grey literature review by Soldani et al. (2018) sets the reported gains, among them independent deployment and fault isolation, against pains that include harder testing, more demanding monitoring and greater consumption of infrastructure.

For registration, the scalability argument is real but narrow. The load peak falls on a few operations, catalogue search and seat allocation, and those could in principle be scaled by other means. The maintainability argument depends on team structure. Conway (1968) observed that a system's structure mirrors the communication structure of the organisation that builds it, and microservices pay off when several teams need to release independently. A university with one small team gains little from independent deployment and inherits all of the operational cost. Fowler (2015) advises starting from a well-structured monolith for this reason.

The step that practitioners report as hardest is deciding where the service boundaries lie (Di Francesco et al., 2018). The principle is older than the style. Parnas (1972) argued that modules should hide design decisions likely to change, and domain-driven design supplies the working tool: the bounded context, a part of the domain within which a model and its vocabulary are consistent (Evans, 2003). In registration, the catalogue, the timetable, student eligibility, enrolment and waitlists, and fees are natural candidates. The word "course" means different things in each, which is the usual sign of a context boundary.

Automated support exists. Mazlami et al. (2017) derive candidate services by clustering classes according to how they change together in version history, and the classification by Fritzsch et al. (2019) groups refactoring approaches by the inputs they need, from static code analysis to workload data. Such techniques assume a codebase with meaningful structure and history. Much of the logic of an older student system sits in database procedures and vendor customisations, where these tools reach poorly, so domain analysis with registrar staff is likely to do more of the work.

The literature is close to unanimous that migration should be incremental. The strangler fig approach places a routing layer in front of the old system and moves functions behind it one at a time until nothing is left to route to the monolith (Fowler, 2004). Newman (2019) catalogues the supporting patterns, among them branch by abstraction, parallel running of old and new implementations, and change data capture to keep two stores in step. The experience report of Balalaie et al. (2016) describes a migration organised as a sequence of such steps and stresses that the delivery pipeline was built before services were split out. Knoche and Hasselbring (2018) report a modernisation that first defined service facades over the legacy system, moved clients onto them, and only then replaced the internals.

The academic calendar gives this advice particular force. Enrolment periods are fixed and public, so a failed cut-over cannot be postponed. Each increment has to be released and proven in a quiet part of the term, and the order of extraction should follow risk. Figure 1 sets out a plausible sequence, pairing each stage with the hazard that the domain makes most likely. Read-mostly functions such as catalogue search come early because an error there is visible and recoverable. Seat allocation comes late, once the team has operated simpler services through at least one peak.

Splitting the database is the part of migration that reports describe as most painful (Taibi et al., 2017). The pattern literature recommends a database per service, with other services obtaining data through interfaces or published events, not shared tables (Richardson, 2018). Once data is divided, an operation that used to be one transaction spans several services. The usual answer is the saga, a sequence of local transactions each paired with a compensating action that undoes it, an idea introduced for long-lived database transactions by Garcia-Molina and Salem (1987).

Enrolment tests this answer severely. Under a network partition a distributed system must give up either consistency or availability (Brewer, 2012), and for seat counts consistency cannot be given up. The practical consequence drawn in the design literature is to keep the invariant inside one service: the component that owns a section's capacity should also own the enrolments counted against it, so that the check and the update remain a single local transaction (Kleppmann, 2017). Eligibility rules that depend on other contexts can be evaluated against replicated data, provided the staleness is bounded and understood. Prerequisites change slowly. A financial hold placed a minute ago may not.

A microservice system has many more moving parts than the monolith it replaces. Automated build, test and deployment are therefore preconditions, not refinements (Humble and Farley, 2010). So are centralised logging, tracing across service calls and monitoring. Calls that were in-process become remote and can fail or stall, and Nygard (2018) describes the timeouts, circuit breakers and bulkheads that stop one slow dependency from exhausting its callers. Fan-out makes matters worse at the peak: Dean and Barroso (2013) showed that when a request depends on many components, the slow tail of each one comes to dominate overall response time. An enrolment request that consults five services is exposed to five tails at precisely the moment each is busiest.

Testing changes character as well. A monolith can be exercised end to end in one process, whereas a set of services needs contract tests at each interface and rehearsals of the whole system under load. For registration the rehearsal that matters is the opening of enrolment, and it can be approximated by replaying recorded request patterns from an earlier term against a staging environment before each release. Running the old and new implementations side by side on the same requests and comparing their answers, the parallel run described by Newman (2019), is well suited to eligibility checks, where a silent difference in a rule would otherwise surface only as a complaint from a student.

Table 1 gathers the lessons that recur across the sources reviewed and states what each implies for a registration platform.

The clearest gap is evidence from the sector. The studies cited here draw largely on commercial software companies and enterprise information systems. Peer-reviewed accounts of registration or student-record migrations, with enough detail on load, team size and outcome to support comparison, would allow the reasoning of this review to be tested. A second gap concerns alternatives. The literature compares microservices with an unreformed monolith far more often than with a modular monolith whose peak-load path has been tuned or scaled separately, which may be the realistic competitor for a small institution.

Third, most universities run vendor systems. Migration then means surrounding a product with services through its interfaces, not decomposing source code, and that situation is little studied. Finally, the effect of data distribution on compliance with records legislation is asserted more often than it is examined, and would repay joint work by software engineers and data protection specialists.

The migration literature does not say that a university should move its registration platform to microservices. It says what such a move costs and how to reduce the risk: migrate behind a facade in small steps, establish automated delivery and observability first, draw boundaries from the domain, and keep the seat-allocation invariant within one service. It also says that the benefits depend on having several teams and a real scaling problem. Institutions that meet those conditions will find well-tried patterns to follow. Those that do not may be better served by restructuring the monolith they have, and the sector as a whole would benefit from publishing what it learns either way.

To be declared by the author(s) before publication.

To be declared by the author(s) before publication.