The system behind an equestrian platform.

01 / CONTEXT

One platform, several connected domains.

The platform brings together horse pedigrees, health and breeding records, farm management, competitions, listings, and subscriptions. These domains share ownership and identity rules: a horse may belong to a farm, staff may act on that farm’s behalf, and access may depend on a subscription.

My responsibility was to make those relationships explicit in the backend and keep the same rules working across mobile, web, administration, and automated jobs. English and Arabic were part of the data and notification design, rather than a presentation-only concern.

• Owned API architecture, PostgreSQL modeling, business rules, integrations, and operational tooling.
• Provisioned AWS infrastructure in Terraform and built the EKS delivery and monitoring workflows.
• Supported the system through dependency upgrades, security reviews, data maintenance, and recovery procedures.

02 / ARCHITECTURE

A modular monolith with explicit boundaries.

Feature modules separate routes, controllers, services, and repositories. Services own domain rules and cross-module workflows; repositories encapsulate Prisma access. This keeps business behavior out of the HTTP handlers and database-access code.

Interface-based service contracts provide test seams and allow dependencies to be replaced. Request validation, centralized errors, and language middleware handle shared concerns consistently.

03 / AUTHORIZATION

Access depends on the resource, not just the role.

Authentication verifies the caller. Authorization then checks platform roles, the ownership or management relationship to the requested resource, and any applicable subscription limits. A farm employee can act through delegated permissions without becoming a platform administrator.

Business permissions are declared in a matrix consumed by middleware. Subscription guards use centralized tier configuration and usage tracking. Keeping these rules shared prevents individual routes from quietly implementing different access policies.

• Resource checks resolve relationships between the caller, a business, and the horse being managed.
• An authorization matrix audit checked routes against the intended policy, with findings tracked through remediation.
• Security headers, CORS configuration, and tighter rate limits on auth and payment routes complement authorization.

04 / DATA

Model relationships once; reuse them across workflows.

PostgreSQL represents users, farms and stables, horse lineage, breeding and health records, and championship results. An operation-user association connects staff to a business with granular permissions. A horse references its sire and dam, allowing the same ancestor to participate in multiple pedigrees.

The gallery uses a virtual aggregation layer to combine profile media, achievements, and championship images without duplicating storage. Results retain source identifiers and read-only flags so writes remain scoped to the originating record.

• User ↔ OperationUser ↔ Business: delegated business access with explicit permissions.
• Horse → sire / dam: self-referencing ancestry rather than copied pedigree records.
• Horse → breeding, health, vaccination, and achievement records: lifecycle history tied to the same identity.
• Event → Championship → Result: competition data feeds configurable points and rankings.
• Redis caches selected read-heavy endpoints with explicit invalidation on writes; aggregate queries use parallel reads and selected fields.

05 / AUTOMATION

Domain events for immediate work. Schedules for time-based work.

Health automation distinguishes a state change from the passage of time. Confirming breeding generates gestation vaccination reminders. Successful foaling schedules weaning reminders for the foal. New horses receive age-based vaccination schedules.

In-process scheduled jobs handle breeding status progression, routine health reminders, and subscription expiry. A manual-run CLI lets operations invoke jobs on demand. These are application listeners and scheduled workers, not a separate distributed event bus.

06 / PEDIGREE

AI-assisted import with validation at the boundary.

Pedigrees arrive as registry pages and chart images. The import service fetches and normalizes registry content with Puppeteer and JSDOM, then asks Claude to extract structured ancestry. Uploaded image types are identified from their bytes rather than trusted client metadata.

The extracted result is checked against the application schema before persistence. Enum values are validated, and existing ancestors are linked instead of duplicated. The model performs extraction inside a controlled import workflow.

07 / INFRASTRUCTURE

An EKS platform with managed data services.

Terraform provisions the VPC, EKS cluster and managed node group, RDS PostgreSQL, ElastiCache Redis, and supporting AWS services. The network separates public and private subnets, with PostgreSQL in private subnets and Redis access scoped to the cluster.

The Node.js Helm chart runs two replicas with resource limits and startup, liveness, and readiness probes. Containers run as non-root with capabilities dropped. ingress-nginx handles routing, cert-manager manages TLS certificates, and application secrets are supplied through Kubernetes Secrets.

• Terraform state is stored remotely in S3 with per-environment stacks.
• Managed node storage uses encrypted gp3 volumes; the application chart sets explicit runtime security and resource controls.
• Prometheus, Grafana, and Loki are deployed as versioned Helm applications through ArgoCD.
• The platform is maintained through EKS minor-version upgrades, ingress security updates, and monitoring chart upgrades.

08 / DELIVERY

GitOps connects a reviewed change to the running service.

Jenkins handles application CI: source and dependency checks, container builds, image scanning, and publication to ECR. The pipeline updates the image reference in the infrastructure repository’s Helm values. ArgoCD reconciles that desired state into EKS.

Infrastructure changes and monitoring installations have separate pipelines. Infrastructure apply and destroy are manual operations rather than side effects of an application push. Trivy image scanning gates the workflow on high- and critical-severity findings.

09 / OPERATIONS

Operations is part of the engineering scope.

Production ownership included cluster and dependency patching, Jenkins backup and restore procedures, and security reviews. A readiness audit covered credential rotation, externalizing secrets, security-group restrictions, and removal of a test database, with remediation tracked to closure.

Application tooling supports database backup and restore, schema drift recovery, CSV imports, and data deduplication. These procedures matter because the system has to remain maintainable after the initial release.

• Jest and Supertest support backend testing; service interfaces make dependencies mockable.
• Prometheus, Grafana, and Loki provide platform monitoring and logs.
• Database migrations run through Prisma’s deployment tooling on application startup.
• Manual job execution and data-maintenance scripts give operations explicit recovery and correction paths.

10 / OUTCOME

A production system with a coherent operating model.

The result is a bilingual backend that carries shared rules across user-facing clients, administration, integrations, and scheduled work. Its infrastructure and delivery path are versioned alongside operational procedures.

This work spans the domain model, access control, workflow automation, AI-assisted import, and the AWS platform that runs the application.