CASE STUDY 02 / 03

Warqah Store

A live commerce platform where backend and infrastructure reliability protect orders, inventory, payments, shipping, and revenue.

System: Production commerce operations platform
Ownership: Backend & DevOps Owner
Technical difficulty: Queue-backed payment, inventory, and fulfillment consistency
Production proof: EGP 21M+ Sales · 100K+ Orders · 90K+ Customers

A production commerce platform engineered to keep orders, inventory, payments, and shipping dependable through high-activity sales operations.

01 / SITUATION

The operating context.

The platform needed production preparation before launch, then ongoing backend ownership as real commercial volume grew.

Warqah Store is a live commerce platform where backend reliability directly affects revenue, order integrity, stock accuracy, payment confirmation, shipping execution, and campaign operations. I joined the project before its public launch and took ownership of preparing the backend and infrastructure for production. This included reworking key queue-processing flows using Redis, configuring the production server, managing deployments and DevOps operations, and implementing the Bosta shipping and Fawaterk payment integrations. I continued owning the backend as the platform launched and grew through real commercial operations.

02 / OWNERSHIP BOUNDARY

What I owned, explicitly.

Role: Backend & DevOps Owner
Ownership model: backend devops owner
Responsibility boundary: Queue-backed payment, inventory, and fulfillment consistency
Project status: live

03 / CONSTRAINTS

What made the system difficult.

Order, inventory, payment, and fulfillment state move together during high-activity operations.
Shipping and payment depend on external Bosta and Fawaterk integrations.
Deployment and queue operations directly affect commercial continuity.

04 / SYSTEM DECISIONS

Boundaries chosen for a reason.

Rework queue-processing flows

Problem: Commercial operations cannot depend on every integration completing inline.
Boundary: Redis-backed processing separates background work from request handling.
Why it mattered: Payment, inventory, and fulfillment work can progress through controlled workers.

Own production infrastructure with the backend

Problem: Application correctness is insufficient when deployment and workers are unreliable.
Boundary: Server configuration, deployments, and DevOps remain in the same ownership boundary.
Why it mattered: Operational failures can be diagnosed and corrected across application and infrastructure layers.

Isolate external commerce integrations

Problem: Shipping and payment providers have independent request and failure lifecycles.
Boundary: Bosta and Fawaterk are implemented as explicit integration boundaries.
Why it mattered: Provider behavior does not become indistinguishable from internal order state.

05 / FAILURE PATHS

Failure belongs in the architecture.

Queue-backed processing prevents long-running integration work from blocking customer requests.
Redis workers support recovery of background commerce operations.
Payment and shipping integrations remain separate from internal order and inventory state.

06 / SYSTEM ANATOMY

Read the boundaries before the components.

Warqah Store architecture overview — Public architecture overview of Warqah Store commerce, queue, payment, shipping, and operational boundaries.

07 / PRODUCTION EVIDENCE

Only the proof the public record supports.

EGP 21M+: Sales
100K+: Orders
90K+: Customers

08 / WHAT CHANGED

The capability left behind.

The backend launched and continued operating through verified sales, order, and customer volume without turning estimates into guarantees.

09 / TECHNICAL STACK

Technology with a job to do.

Laravel 12: Commerce rules, order state, inventory, and integration orchestration.
Laravel Sanctum: Authenticated application access.
Redis: Queue-backed commercial workflows.
Bosta API: Shipping execution boundary.
Fawaterk: Payment integration boundary.
Telescope: Supporting production technology.