Skip to main content

Documentation Index

Fetch the complete documentation index at: https://mintlify.com/apursley2012/dev-nexus/llms.txt

Use this file to discover all available pages before exploring further.

The Case Studies page (/case-studies) reframes engineering post-mortems as “rituals” — ceremonial write-ups of complex technical conjurations. The page currently features a single deep-dive case study covering a legacy monolith migration to microservices. The content is structured into five labeled sections mirroring a ritual procedure: intent, materials, method, outcome, and lessons learned. The tone is analytical but maintains the site’s arcane framing throughout.

​
Route & Navigation

PropertyValue
Route/case-studies
Nav LabelRITUALS
Page HeadingRITUALS PERFORMED
Subheading// DETAILED POST-MORTEMS OF COMPLEX CONJURATIONS

​
Current Case Study

​
MIGRATION OF THE LEGACY MONOLITH

RITUAL_ID: 0x7A9B
The case study is divided into five numbered sections:

​
I. INTENT

Decouple a monolithic application into three independent microservices:
  • Auth Service — handles authentication and session management
  • Billing Service — isolates payment processing logic
  • Inventory Service — manages product and stock data
The goal was to enable independent deployment, improve fault isolation, and reduce build times.

​
II. MATERIALS

The migration used the following stack:
MaterialRole
Node.js / ExpressService runtime and HTTP layer
Docker & KubernetesContainerization and orchestration
PostgreSQLPer-service relational data stores
Redis (Pub/Sub)Asynchronous inter-service messaging
GraphQL FederationUnified API layer across services

​
III. METHOD

The Strangler Fig pattern was chosen to allow incremental extraction without a risky big-bang cutover. An API gateway was introduced in front of the monolith, routing new traffic to extracted services while legacy routes continued hitting the monolith: 
// API gateway routing logic — gradual traffic migration
if (req.path.startsWith('/api/profiles')) {
  return routeToProfileService(req);
}
return routeToMonolith(req);
Services were extracted one at a time. The API gateway’s routing table was updated as each service reached production readiness, progressively strangling the monolith.

​
IV. OUTCOME

The migration produced measurable improvements across all tracked metrics:
MetricBeforeAfter
Build time45 minutes3 minutes
Uptime99.1%99.99%
Developer sanityDepletedRestored

​
V. LESSONS

Two hard-won lessons emerged from the migration:
  1. Use CDC tools for data synchronization. Debezium (Change Data Capture) proved essential for keeping data consistent across services during the transition period, capturing database-level change events rather than relying on application-layer sync logic.
  2. Dual-write race conditions are treacherous. During the period when both the monolith and a new service were writing to overlapping data, race conditions introduced subtle inconsistencies. A strict write-ownership model (one service owns each entity) should be enforced before, not after, cutting over traffic.

​
Visual Structure

Each of the five sections is rendered as a distinct panel with a Roman-numeral section label. The RITUAL_ID identifier is displayed in a monospace badge at the top of the case study. The gateway code block uses standard syntax highlighting with the site’s dark color scheme applied.

​
Animations

The five sections entrance-animate sequentially using whileInView, so each section fades in as the user scrolls past it — reinforcing the sense of a ritual being revealed step by step. 
// Section reveal pattern used across all five panels
<motion.section
  initial={{ opacity: 0, y: 32 }}
  whileInView={{ opacity: 1, y: 0 }}
  viewport={{ once: true }}
  transition={{ duration: 0.6 }}
>
  {/* Section content */}
</motion.section>

​
Customization

Adding a new case study: The page currently renders a single case study. To add more, create a case studies data array and map over it. Each case study should follow the five-section structure (intent, materials, method, outcome, lessons) for consistency. 
// Case study entry shape
{
  id: "0x3F2C",
  title: "TITLE OF THE RITUAL",
  sections: {
    intent: "What problem was being solved.",
    materials: [{ name: "Tool", role: "Purpose" }],
    method: "How the work was approached.",
    outcome: [{ metric: "Name", before: "X", after: "Y" }],
    lessons: ["Lesson one.", "Lesson two."]
  }
}
Updating the code example: The gateway routing snippet in Section III is hardcoded JSX. Replace it with a more accurate or updated example by editing the <pre> or code block element in the Method section of the component. Updating outcome metrics: The before/after metrics table is hardcoded. Extract these into a metrics array on the case study data object to make them easier to update without touching JSX.
The RITUAL_ID hex value (0x7A9B) is purely decorative. If you add multiple case studies, assign each a unique hex ID — generate them randomly or derive them from the project name for a consistent feel.
The Debezium link in the Lessons section is the only external hyperlink on this page. Ensure it points to the correct URL if the content is updated. All other links on this page are internal.

Build docs developers (and LLMs) love

Get started for freeTalk to us