Java · Spring Boot · REST APIs · MySQL
I’m Ata ur Rahman Shahid. I build Java and Spring Boot services, with Node.js jobs where they fit, that connect marketplaces, order-management systems and ad platforms to internal tools, plus the data pipelines and reports built on them.
Looking for backend engineering roles where integration work and reliable data matter.
Selected work
A tool I designed and built on my own: the operations team uploads a spreadsheet of order splits, a Node.js worker carries them out through the SellerCloud API, and every row comes back with the new order ID or the error.
A profit engine that reads the settlement files from every sales channel, maps every fee, penalty and chargeback to a single chart of accounts, and produces a monthly P&L for every account, product family and SKU.
A pipeline that pulls orders, costs and ad spend from three systems that didn’t share an ID into one daily profit figure per product family, with year-over-year comparisons one click away.
Turns an Amazon Vendor Central PO export into one sheet with the SellerCloud order, kit and packing rules and two-warehouse stock filled in, plus a check of which competing POs the stock can cover.
What I work on
Much of my work starts where systems do not quite agree: different APIs, incomplete records, changing business rules, and reports that need to be trusted. I design the processes that bring that information together and make it usable.
Connect external platforms and internal applications through APIs, scheduled synchronization, and careful error handling.
Collect, clean, reconcile, and present operational and financial data.
Build services and internal tools that support day-to-day decisions and workflows.
Investigate failed jobs, inconsistent numbers, performance issues, and unexpected behavior.
Tools Java, Spring Boot, MySQL, JDBC and REST APIs day to day; Node.js, BigQuery and JavaScript where the work calls for them.
Approach
I start by understanding where the data comes from, what a result is supposed to mean, and how the system should behave when a dependency fails. I care about readable code, observable jobs, clear data definitions, and tools that remain useful after their first release.
Make it possible to explain where a number came from.
Expect API errors, partial data, retries, and changing inputs.
Build around the questions people actually need to answer.
Contact
If my experience is relevant to your team or project, I’d be glad to hear from you.