HOVHANNES KHACHATRYAN

05 — CASE STUDY

Large-Scale Legal Information & Research Platform

Back-end and data work on an existing legal-information system whose MySQL database contained more than 200 tables, interconnected legal records, and production import and update workflows.

Legal technology · Data systemsBack-end, data evolution & integrationAnonymized legal-domain systems

OVERVIEW

Context

The system stored and connected legal documents, articles, references, precedents, markers and annotations, and multilingual content, with production workflows for importing and updating that data.

PROBLEM

What had to be solved

Changes could affect chains of relationships across more than 200 tables and existing production records. Schema and data transformations, imports, and query changes therefore had to preserve the links among legal articles, references, precedents, markers, and language-specific content.

CONSTRAINTS

System boundaries

  • The relational database contained more than 200 tables and existing production data.
  • The adapted implementation needed independent system and data boundaries while retaining the required legal relationships and multilingual structures from the existing model.

MY RESPONSIBILITY

Back-end, data evolution & integration

  • Implemented PHP/MySQL back-end changes, import and update flows, schema and data transformations, and query/index work within the existing production system.
  • Reused applicable structures from the existing model for a separate legal-domain system, then changed domain-specific records, references, and relationships so the implementation remained independent.
  • Implemented the application's online payment workflow through a bank POS integration.

ARCHITECTURE

System model

Legal information architectureThe PHP application handled legal content, imports and updates, and online payment as separate workflows. The payment flow belonged to the application, not to the legal-reference model itself.
Application workflows
Documents / articlesImports / updatesPayment workflow
PHP application · Domain logic
Legal relationships · References · Markers
MySQL · 200+ table relational model

ENGINEERING CHALLENGES

Where the complexity lived

  • Determining which relational structures could be reused and which legal-domain records, references, and relationships had to change for the separate system.
  • Applying schema and data transformations without breaking dependent legal records already present in production.
  • Reviewing indexing and query behavior as import/update workflows and data structures changed across the 200+ table model.
  • Integrating a bank POS payment flow while keeping credentials, merchant configuration, and signatures private.

APPROACH

How the solution was structured

  • Reused structures that applied to both legal domains, changed domain-specific relationships where required, and kept the resulting implementation and data independent.
  • Treated existing production records and their dependent legal relationships as constraints when changing schemas, imports, and update logic.
  • Implemented payment as a separate application workflow, keeping vendor-specific request handling distinct from the core legal-information relationships.

OUTCOME

What the work established

  • Delivered back-end and data changes that adapted the existing legal-information model for a separate legal-domain system while preserving required relationships, import/update behavior, and independent data boundaries. The broader product work also included an online bank POS payment workflow.

TECHNICAL CONTEXT

Technologies and systems

PHPMySQLRelational data architectureBank POS integration

Product names, private table names, production data, payment credentials, merchant identifiers, request signatures, and proprietary implementation details are omitted.