This post is co-written with James Chao, Distinguished Software Engineer from Turnitin.

In this post we discuss how Turnitin migrated from a monolithic frontend to a micro-frontend architecture built on AWS to support their growth, improved user experience and faster feature releases. We’ll discuss their previous monolithic frontend architecture, the key drivers for an architectural change, the new micro-frontend architecture, migration process and achieved benefits.

About Turnitin

Turnitin is a global leader in academic integrity and assessment solutions, serving educational institutions worldwide with tools that promote academic integrity, streamline grading and feedback, and improve student outcomes. With millions of students and educators relying on their platform daily, Turnitin needed a scalable, efficient architecture that can evolve with changing educational technology needs.

Previous architecture

Figure 1: Previous monolithic architecture where client applications were tightly coupled with multiple backend services

Prior to modernization, Turnitin operated with a monolithic frontend architecture that became more challenging as the company grew. Each client application was built as a single, tightly coupled codebase that directly interfaced with multiple backend services through AWS.

In this architecture:

• Client Applications 1 and 2 were developed as separate monoliths
• Both applications connected directly to multiple backend services (Service A, B, and C)
• Backend services were built on AWS using Amazon API Gateway, AWS Lambda, and Amazon DynamoDB
• Development teams faced bottlenecks when multiple teams needed to work on different features
• Code reuse between applications was difficult, leading to duplicate implementations
• Integrating acquired companies and products became increasingly complex

This monolithic architecture initially met Turnitin’s requirements but became constrained as products evolved. Tight interdependencies created friction and complexity.

Key drivers for modernization

Turnitin’s modernization business drivers were to enhance development efficiency, scalability, and rapid capability integration across its product portfolio. The initiative focused on removing redundant features. This would allow the optimization of resources while implementing a future-proof, framework-agnostic architecture. This optimization enabled flexible incorporation of new products from acquisitions and accelerated deployment of innovative features like AI writing detection. Through these improvements, Turnitin aimed to enhance organizational agility, minimize technical debt, and maintain adaptability to respond swiftly to market needs, particularly regarding generative AI advancement.

How micro-frontends on AWS solved the problem

Turnitin implemented a client-side rendering micro-frontend architecture on AWS that decomposed their monolithic frontend into independent units while maintaining a seamless user experience. This approach eliminated development bottlenecks by giving teams autonomy to develop components without coordination across the entire application. Each micro-frontend aligned with specific business domains, creating clear ownership boundaries and allowing teams to develop specialized expertise.

The architecture enabled sharing components across different applications, reducing code redundancy. While this approach facilitated technology flexibility, Turnitin implemented a disciplined framework through a reference architecture with pre-approved tooling. This balanced structure allowed teams to select appropriate tools from a curated list while adhering to interface standards. It also simplified the integration of acquisitions as standalone components with well-defined interfaces, without creating technical debt through uncontrolled technology proliferation.

The architecture leverages several AWS services: Amazon CloudFront delivers content globally with environment-specific configurations, while Amazon S3 securely hosts static assets. Backend services are powered by AWS Lambda and Amazon API Gateway, which are carefully mapped to their corresponding frontend components. Amazon Route 53 handles DNS routing to ensure reliable traffic distribution. Independent CI/CD pipelines were configured for each micro-frontend, supporting rapid, parallel deployment cycles that accelerated innovation.

New architecture

Figure 2: New micro-frontend architecture featuring decomposed frontend components with clear service boundaries and improved modularity

Turnitin’s new micro-frontend architecture is a different approach in how frontend applications are structured and deployed. The architecture decouples frontend components while maintaining a cohesive user experience.

Key elements of the new architecture include:

• Client applications 1 and 2 serve as shells hosting multiple independent micro-frontends (A, B, and C) developed by autonomous teams
• Micro-frontends communicate exclusively with their corresponding backend services, creating clear domain boundaries
• Micro-frontend B is reused across both client applications, demonstrating feature sharing capabilities
• Backend services continue leveraging AWS infrastructure but with clearer ownership aligned to specific frontend components
• Amazon CloudFront delivers the micro-frontends globally with environment and geo-specific configuration

This architecture enables Turnitin to implement new capabilities faster by leveraging framework-agnostic web components that are compatible with modern browsers. The domain-focused approach creates clear boundaries of responsibility, empowering teams to innovate within their domains while maintaining system-wide coherence.

Migration process

Turnitin migrated its existing monolithic applications to a distributed architecture using an incremental, in-place transformation approach with micro-frontends. New functionality was built as micro-frontends and integrated into the existing applications. As users adopted the new micro-frontend features, the older monolithic components were gradually deprecated and removed.

The steps below describe the process for the in-place migration:

1. Defined Domains: The team analyzed the monolith and grouped its functionalities into logical business domains. If the organization was already using a micro-service architecture, functionalities within a domain were likely already using the same backend services.
2. Identified Functionality to Replace: Developers identified specific parts of the UI or workflow steps within the monolith that belonged to a chosen domain.
3. Built the Micro-Frontend: The team developed the new micro-frontend to replicate the functionality and UI, and ideally add improvements to deliver business value. They designed it for reusability and ensured it could function as a standalone component. The micro-frontend included both presentational UI code and non-UI business logic, such as sending API requests to its domain backend. By encapsulating both UI and logic related to the functionality, the micro-frontend would ultimately replace the corresponding presentation UI code and business logic code in the monolith.
4. Replaced In-Place: The developers carefully swapped out the old monolithic UI with the new micro-frontend within the existing application. This involved wrapping the old UI/code path in conditional statements, with the alternate code path displaying the new micro-frontend component. The old code could be purely presentational UI code or non-UI code such as API requests. The conditional statements were controlled by feature flags, allowing the team to show the micro-frontend only to a small percentage of customers or only to new customers during the transition.
5. Iterated & Expanded: The team monitored the new micro-frontend for errors and business metrics to ensure it was achieving business goals and to enable quick resolution of any issues. Once stable, they decommissioned the old code from the monolith by removing the conditional block that used the old UI/code path, ensuring all users would now use the micro-frontend. Since the micro-frontend now provided the complete functionality (both UI and business logic), the existing code in the monolith for that functionality was no longer needed and could be removed. The team then repeated these steps for other UI parts and domains, progressively shrinking the monolith.

This approach minimized disruption to the business while enabling a steady progression towards the target micro-frontend architecture. The move to distributed architecture demanded organizational changes, including team training in micro-frontend concepts, development of shared components, and a strategic shift toward reusable, component-based design.

The key objectives were adopting modern cloud architecture principles, improving developer productivity and velocity, and enabling more frequent, decoupled deployments of new features. Success metrics included increasing micro-frontend adoption, reducing monolithic dependencies, and improving overall application performance and reliability.

Achieved outcomes

Turnitin’s migration to micro-frontend architecture yielded significant technical and business improvements:

• Delivery speed improved as independent teams deployed features without coordinating across the entire application
• Cross-product functionality was successfully implemented with seamless integration across multiple client applications
• User experience improved through shared UI component libraries establishing uniform interfaces
• Greater scalability enabled each micro-frontend to scale independently based on demand
• Acquisition integration accelerated as new acquisitions integrated as standalone components through well-defined interfaces
• Developer satisfaction increased with autonomous teams reporting improved productivity and reduced cross-team dependencies

This architectural transformation established the foundation for Turnitin’s continued product evolution, particularly supporting their rapid response to emerging educational technology needs.

Conclusion

With AWS’s global infrastructure, auto-scaling features, and high availability, Turnitin can now seamlessly scale to support surges in global traffic and provide reliable service to educational institutions worldwide. The decoupled nature of micro-frontends also enhances system resilience while maintaining a cohesive user experience across their product portfolio.

This architectural transformation has empowered Turnitin to advance their core mission of upholding academic integrity in the age of generative AI. Their modernized platform enables rapid deployment of innovative tools like AI Writing Detection, which provides instructors with essential resources to address new challenges in academic integrity. The upcoming launch of Turnitin Clarity brings transparency to the writing process, increasing confidence for both instructors and students while incorporating an AI assistant designed to foster responsible use of AI tools. Additionally, their Paper-to-Digital solutions increase efficiency for paper-based assessments by automating tedious steps and providing AI-assisted grading.

By embracing modern architecture principles and AWS technologies, Turnitin has positioned itself to bring new educational technology solutions to market faster, accelerate global growth, and maintain a competitive edge through continuous innovation and technical excellence—all in service of their mission to promote academic integrity and improve student outcomes worldwide.

About the Authors