Raju Rayhan
Head of Development · AI Platform Architect
Available · Q3 2026
← work / edp — defense procurement
Case 02 · 2019 — 2023 · Government platform

eDP Defense Procurement

A national defense-procurement platform for the Bangladesh Directorate General of Defense Purchase (DGDP), Ministry of Defense. Live at edp.gov.bd. Architected as a Java Spring Boot microservices system with a React frontend and Oracle backbone — role-scoped, audit-logged, and built to survive procurement cycles measured in years.
JavaSpring BootMicroservicesReactOracleRedisSwaggerDocker
4y
Architect · Team Lead
12+
Microservices shipped
gov
Production · edp.gov.bd
Audit trail retention
§ 01 The brief
Context

DGDP manages defense procurement for the Bangladesh Armed Forces. Tenders, bidders, contracts, amendments, deliveries, and audits — all of which had lived on paper, email, and a patchwork of legacy tools. The mandate: bring the whole pipeline online with the discipline the domain deserves.

Constraints
  • High-security posture — every action is auditable, signed, and reviewable.
  • Multi-role workflows — procurement officers, vendors, auditors, senior command.
  • On-prem Oracle; no cloud-managed DB options on the table.
  • Procurement regulations change by gazette, not by JIRA.
The hardest part wasn't writing the code. It was mapping a decades-old paper process into a schema that could survive the next decade without another rewrite.
— from the architecture notes
§ 02 The architecture simplified
         ┌──────────────────────┐     ┌──────────────────────┐
         │  Officer Portal      │     │  Vendor Portal       │
         │  React · role-scoped │     │  React · KYC gated   │
         └──────────┬───────────┘     └──────────┬───────────┘
                    │                            │
                    └─────────────┬──────────────┘
                                  │
                     ┌────────────▼────────────┐
                     │      API Gateway        │
                     │  auth · routing · logs  │
                     └────────────┬────────────┘
                                  │
     ┌────────────────┬───────────┼───────────┬────────────────┐
     │                │           │           │                │
┌────▼────┐    ┌──────▼──────┐ ┌──▼───┐  ┌────▼─────┐   ┌──────▼──────┐
│ Tender  │    │  Bidder /   │ │ Doc  │  │ Contract │   │   Audit &   │
│ Service │    │  KYC        │ │ Vault│  │ Service  │   │  Notification│
└────┬────┘    └──────┬──────┘ └──┬───┘  └────┬─────┘   └──────┬──────┘
     │                │           │           │                │
     └────────────────┴────┬──────┴───────────┴────────────────┘
                           │
                   ┌───────▼────────┐       ┌───────────┐
                   │   Oracle DB    │◄──────┤   Redis   │
                   │ · partitioned  │       │ · sessions│
                   │ · audit-logged │       │ · queues  │
                   └────────────────┘       └───────────┘
§ 03 A few decisions
03.1
Microservices along domain seams, not team seams

We split services by procurement lifecycle — tender, bidder, contract, audit, documents — so each piece could evolve at its own cadence as regulations changed. Team boundaries moved; service boundaries didn't have to.

03.2
Every mutation produces an audit event, always

The audit service was first-class, not bolted on. Every state transition across every service emitted a signed event consumed by a dedicated audit store. When the comptroller asked a question, we had an answer in one query — not a forensic expedition across logs.

03.3
Role-scoped views over permission flags

Instead of a tangle of boolean permissions, we modeled roles as composable scopes. An auditor saw a different UI from an officer from the same endpoint, because the endpoint shaped its response to the caller. Fewer bugs, fewer leaks.

03.4
Oracle is not Postgres — stop pretending

We leaned into Oracle's strengths — partitioned tables for tender archives, proper materialized views for dashboards, PL/SQL where it actually earned its keep — instead of writing the platform as if the DB were interchangeable.

§ 04 Outcomes
Before
  • Tender documents shuttled by hand between offices
  • Bidder verification stretched over weeks, manually
  • Audit trail reconstructed after the fact, if at all
  • Amendments lost in email threads
After
  • End-to-end procurement online at edp.gov.bd
  • Digital KYC + role-scoped bidder onboarding
  • Every action signed, every state change audit-logged
  • Amendments versioned, diffed, and traceable
Next case
The Hive — Internal AI ops
Read next →