Medlync

Association

Medlync is associated with Tecciance.

What it is

Medlync is a healthcare platform built around an eight-service microservices architecture. The engineering work centered on reliability, clean service boundaries, workflow orchestration, reusable backend standards, and infrastructure that could support a production-grade healthcare system.

The system needed more than independent REST services. It needed predictable orchestration, retry behavior, controlled downstream failure handling, and shared conventions that kept every service from solving the same platform problems differently.

Surface-level view on what I worked on

flowchart LR
  Client[Web and mobile clients] --> Gateway[API layer]
  Gateway --> Services[8 Spring Boot microservices]
  Services --> Orchestrator[Temporal orchestrator]
  Orchestrator --> Downstream[Downstream APIs and async jobs]
  Services --> DB[(PostgreSQL)]
  Services --> Cache[Cache resolver library]
  Infra[Terraform on AWS] --> Services

What I built

I contributed to the planning and architecture of the eight microservices, including service boundaries, communication contracts, database isolation, and the common patterns each service would follow. Most of my work was backend-heavy: Spring Boot services, PostgreSQL data modeling, Flyway migrations, API contracts, and the shared libraries the services depended on.

The orchestrator service was one of the core pieces I owned end to end. It used Temporal workflows to make long-running business processes explicit, retryable, and easier to reason about. That gave the system a safer way to handle downstream API failures without scattering retry logic and failure branches across every service.

I also built two reusable libraries independently and helped develop another shared library:

• a common standards library for logging, exception handling, API response formats, utility modules, and project defaults
• a cache resolver library with custom cache groups, cache-first resolution, Memcached integration, and automatic revalidation behavior

Those libraries were designed to outlive the project. The common standards library is now used company-wide, and the cache resolver can be reused by other backend systems that need consistent cache behavior without rewriting the same resolver layer.

Frontend and mobile

Although the project was backend-heavy, I also contributed to the frontend and built a complete mobile application using Expo Go. That meant working across web, mobile, service APIs, and infrastructure instead of treating the backend as a separate island.

An interesting local development approach

For local development, I set up two Linux machines with an NGINX reverse proxy and SSL support. That made the full local environment accessible from a mobile app, so mobile flows could be tested against local microservices without depending on deployed environments.

Infrastructure

I implemented the AWS infrastructure setup with Terraform, covering the core cloud resources needed by the microservice platform. The project also involved AWS messaging and serverless services such as SQS, Step Functions, Lambda, SES, and SNS where they fit the workflow and notification model.

What it changed

The architecture reduced cross-service coupling by about 40%, while the Temporal orchestration layer reduced asynchronous workflow failure rates by 35%. The shared cache resolver cut database load by roughly 45% and improved API response time by about 30% across integrated services.

The Terraform setup improved deployment consistency by 60% and supported 99.9% uptime across the AWS footprint. The local Linux and NGINX environment also shortened feedback loops by making the complete web, backend, and mobile system testable before deployment.