MostafijurRahaman

Software architect · systems thinker · entrepreneur

I build reliable platforms, useful products, and stronger engineering organisations.

I lead architecture and engineering for high-traffic platforms, turning complex operational problems into scalable, reliable products.

Explore work Get in touch

10+
years building software
~2M
daily requests
99%+
platform uptime
~37%
cloud infrastructure cost reduction
Reduced cloud infrastructure costs by approximately 37%.

Work

Selected work

Writing

Ideas

Modernising a High-Traffic Laravel Monolith Without Disrupting Production
Backend Architecture · 28 July 2026 · 3 min read
A practical approach to evolving a busy Laravel codebase: reduce risk first, extract only when the boundary is real, and keep production operable throughout.
Designing Notification Systems That Survive Real Traffic
System Design · 28 July 2026 · 2 min read
Notifications look simple until retries, fan-out, preferences, and provider failures show up. Here is a durable mental model for building them as an operable subsystem.
How I Think About Engineering Quality, Delivery Speed, and Technical Debt
System Design · 28 July 2026 · 2 min read
Quality, speed, and debt are not slogans. They are competing constraints. Here is a practical way to negotiate them without pretending trade-offs do not exist.

Beliefs

Principles

A path that survives production load, operations, and change is more valuable than a polished demo that only works on the happy path.
Most of the risk in backend and platform work shows up after the first demo: traffic patterns, failure modes, deployments, and the cost of changing the system later. I bias toward designs and delivery choices that stay operable—observable, recoverable, and evolvable—even when that means a slower first screenshot.
Engineering decisions are easier to trust—and revisit—when constraints, options, and what you gave up are stated plainly.
Hidden trade-offs create false confidence. Teams and future-you need to know what was constrained, what was rejected, and why the chosen path won. I treat constraints and trade-offs as first-class narrative in case studies and reviews, not as footnotes after the architecture diagram.
End-to-end ownership—from framing the problem through architecture, delivery, and production care—beats handoff theater.
Reliable platforms and products improve when someone stays accountable across the whole path: context, design, shipping, and what happens after launch. That ownership can be shared across a team, but it should not dissolve into unclear handoffs where no one owns outcomes.