SYSTEM / 04

MyDocki

A multi-service healthcare platform coordinating care, providers, payments, operations and last-mile fulfilment.

Visit MyDocki (opens MyDocki website in a new tab)
Patient and provider activity enters a core healthcare API, with administration, logistics, notification workers and file storage handled through separate operational boundaries.
ROLEBackend Lead / Fullstack Engineer
PERIOD2025—Present
ARCHITECTUREModular / Queue-backed services
01 / CONTEXT

A system shaped by real-world constraints.

MyDocki brings multiple healthcare journeys into one platform, connecting patients with doctors, pharmacies, laboratories, hospitals, healthy-meal providers and emergency support.

The operating model extends beyond consultations. Provider onboarding, payments, administrative review, notifications and last-mile delivery all need to remain coordinated without becoming one tightly coupled workflow.

02 / ROLE & OWNERSHIP

Where I contributed.

  • Backend leadership and full-stack engineering across the core healthcare API, operational administration, logistics, notification processing and file-upload boundaries.
  • Designed and delivered patient, provider and administrative workflows alongside the supporting payments, wallets, delivery and communication infrastructure.
03 / CONSTRAINTS

What made the work difficult.

  • Patients, providers, administrators and riders each needed distinct access and state transitions across sensitive identity, healthcare and operational records.
  • Delivery, payout and wallet updates needed to remain consistent when provider callbacks failed, arrived more than once or completed after an internal state change.
  • Time-sensitive notifications and webhooks needed to tolerate retries without producing duplicate communication or repeated downstream work.
04 / ENGINEERING DECISIONS

What mattered technically.

Separated operational boundaries

Kept the core healthcare platform, logistics domain, notification workers, file uploads and administrative application behind explicit service boundaries so each workload could evolve and fail independently.

Failure-aware messaging

Queued email, WhatsApp, push, reminder, scheduled-payment and webhook work with validated payloads, exponential retries, idempotency keys and dead-letter handling.

Transactional fulfilment and payouts

Coordinated delivery, rider, wallet and payout state with database transactions, recorded status history, duplicate-event tracking and recoverable wallet refunds.

Operational traceability

Combined scoped administration and audit records with structured logging and New Relic telemetry so operational work and failures remained inspectable.

05 / RELIABILITY & SECURITY

Correctness beyond the happy path.

  • Redis-backed sessions, service API keys, signed webhooks, request validation and rate limiting protect system boundaries.
  • MongoDB transactions and idempotency controls keep delivery, wallet, payout and notification state recoverable across repeated or partial work.
  • Queue workers use retries, dead-letter handling, structured monitoring and graceful shutdown behavior.
06 / TECHNOLOGY

Technology should support the system, not become the story.

TypeScript · Node.js · Express · NestJS · Next.js · MongoDB · Redis · BullMQ · AWS S3 · Paystack · New Relic

← ALL SELECTED SYSTEMS