Madar

Overview

Madar is a team-built logistics orchestration platform operating at approximately 8,000–10,000 daily shipments, approximately 2.5 million total shipments, and approximately 30 integrated fleets at the approved reporting point.

As a Senior Backend Engineer, I contribute to architecture and technical design decisions, implement core backend capabilities, and carry work through production. My scope spans logistics workflows, external integrations, asynchronous processing, data-intensive workloads, performance, operational automation, and reliability. I also guide junior and mid-level engineers while remaining hands-on with implementation and production problem-solving.

The platform and its outcomes belong to the wider team. This case study covers the areas I owned or materially contributed to without describing the complete proprietary system.

My role and scope

• Contribute to backend architecture, system boundaries, and implementation decisions.
• Design and implement core logistics capabilities through deployment and production operation.
• Build and evolve fleet integrations and asynchronous processing workflows.
• Improve PostgreSQL workloads, exports, scheduled processing, and operational automation.
• Investigate difficult production issues with engineering, operations, and other collaborators.
• Review code and help junior and mid-level engineers reason through design and implementation.

This is technical leadership within a hands-on engineering role, not a claim of formal people management or sole platform ownership.

Core platform engineering

My work is part of the platform’s operational core: shipment assignment, pricing, invoicing, reporting, fleet onboarding, and shipment-lifecycle automation. I have designed and implemented reminder and reassignment flows, narrowed scheduled processing to eligible shipments, and helped shape boundaries for provider-specific behavior.

These capabilities connect business rules to real logistics operations. The engineering challenge is not simply exposing endpoints; it is keeping state transitions and scheduled actions predictable while external fleets and operational conditions change independently. Proprietary assignment and pricing rules are intentionally omitted.

Architecture and distributed workflows

I participate in decisions about where logic belongs, which work should remain synchronous, and where asynchronous boundaries make failure and recovery easier to control. In the areas relevant to my work, NestJS and TypeScript services coordinate PostgreSQL-backed workflows, RabbitMQ-supported background processing, and fleet integration boundaries.

For a strategically important integration, I designed and advocated for an isolated adapter service. That introduced another operational boundary, but contained provider-specific change instead of allowing an external contract to spread through core logistics logic.

The diagram above is deliberately simplified. It communicates the boundaries relevant to my work, not the complete production architecture.

Performance engineering

Problem

Critical shipment-list filters used by operations had become too slow as data volume and query complexity increased.

Investigation

I examined the generated PostgreSQL queries and their access patterns rather than treating the endpoint or infrastructure as a black box. The expensive paths involved query shape, joins, and how the database accessed filtered data.

Technical decision

I combined query redesign, targeted indexes, join simplification, and purpose-built SQL for the critical path. The trade-off was a more specialized data-access path that required explicit maintenance, in exchange for predictable performance where a generic query shape was insufficient.

Result

The changes reduced latency by more than 90% on the identified critical PostgreSQL workloads. This is a scoped workload result, not a platform-wide performance claim.

High-volume export processing

Problem and constraint

Large exports performed too much work inside a synchronous request and depended on assembling a large result in memory. That limited supported export size and made resource use harder to control.

Approach

I moved export generation into queued background work and processed data incrementally through streaming and chunking. This separated requesting an export from executing it, at the cost of additional job state and operational handling.

Result

The redesign increased supported export capacity by 10×. The result describes the capacity of this workflow, not overall platform throughput.

Reliability and operational automation

Logistics workflows operate across system boundaries where timeouts, partial states, delayed responses, and provider-side failures are normal constraints. Reminder, reassignment, and scheduled shipment processing therefore need bounded work, observable state, and recovery paths rather than assuming every operation completes in one pass.

I have worked across deployment, monitoring, incident investigation, targeted production data correction, and cross-functional debugging with the wider team. Production feedback informs the next design decision; incident details, identifiers, customer data, and internal tools remain private.

Integrations and ecosystem context

Madar coordinates workflows across vendors, operational teams, and multiple fleet providers in the Saudi logistics context. My work includes fleet onboarding, technical evaluation, integration workflows, and isolation of provider-specific behavior.

This public account keeps organizations and contracts generalized. It does not imply that every platform participant is a direct API integration or that I personally implemented every external relationship.

Technical leadership

Alongside implementation, I help junior and mid-level engineers work through design choices, code reviews, debugging, and difficult production problems. That includes sharing system context, challenging assumptions, and helping turn broad requirements into maintainable changes.

I remain responsible for writing and shipping code. The leadership described here is technical guidance and collaborative problem-solving, not formal people management.

Selected outcomes

• More than 90% lower latency on critical PostgreSQL workloads.
• 10× greater supported export capacity after moving work to queued, streaming, and chunked processing.
• Architecture through production: hands-on responsibility across core backend capabilities, integrations, automation, and production operation.
• Technical guidance: support across design, implementation, reviews, debugging, and production problem-solving.

These examples demonstrate the range of the role; they are not an exhaustive list of the platform’s work or outcomes attributable to one engineer.

Key takeaways

• Senior backend ownership connects architecture decisions to implementation and production feedback.
• Scale problems are often workflow problems as much as database or infrastructure problems.
• Asynchronous processing adds value only when failure, recovery, and observability are part of the design.
• Technical leadership is strongest when it improves both the system and how engineers reason about it.

Technologies in context

Node.js, NestJS, TypeScript, PostgreSQL, and RabbitMQ support the areas described here. The important evidence is how those tools serve core workflows, integration boundaries, data performance, asynchronous processing, and reliable production operation.