Registration & management
Customers register multiple webhooks and subscribe each one to different events.
Open to remote & hybrid backend roles
Backend engineer at Fin.com, building event-driven Go microservices for payments, where correctness and data integrity matter most.
package main
type Engineer struct {
Name string
Role string
Stack []string
Chains []string
WorkMode []string
}
func main() {
me := Engineer{
Name: "Md. Shahria Islam Nihal",
Role: "Software Engineer L2 @ Fin.com",
Stack: []string{
"Go", "SQL", "Microservices",
"Event-driven", "Web3",
},
Chains: []string{"EVM", "SVM", "TVM"},
WorkMode: []string{"Remote", "Hybrid"},
}
hire(me) // 👋
}
01 / about
I'm a backend engineer in Dhaka, Bangladesh. At Fin.com I'm part of the core team that built our microservices from scratch, with most of my work in payments.
Before that I wrote Java at Therap and C#/.NET at Orbitax.
> Looking for Go backend roles, especially in fintech and critical systems.
Kafka and RabbitMQ between services, and async work without race conditions.
Exchange payments, onboarding and on/off-ramp flows for a B2B platform.
State machines, idempotency and tuned PostgreSQL keep data consistent.
02 / experience
Cross-border payments infrastructure · core backend team · Fin.com Orchestration
Healthcare SaaS · large monorepo
Tax technology · core backend team
03 / highlights
A look at some of the systems I've designed and built.
Designed and built end to end on my own. Customers register webhooks for the events they care about, and every event reaches them reliably.
Customers register multiple webhooks and subscribe each one to different events.
When an event fires, it is sent to every webhook subscribed to it.
Failed deliveries are retried automatically, and customers can also retry them manually, so a short outage on their side loses nothing.
I added state machines to customer onboarding and transaction flows, so the next step from any state is always defined.
Every state has a fixed set of next steps, so the flow never has to guess.
Invalid transitions are rejected, so a flow can't skip a step or break a rule.
Because each state is explicit, a failed step can be retried without side effects.
Designed and built on my own. Other services send it a simple request and get back reliable, idempotent transactions on EVM, SVM and TVM chains. It puts correctness before speed.
Integrated Circle, Privy and Fireblocks, using their wallet and transaction APIs.
Raw transactions over RPC (QuickNode and other providers): create and broadcast, then monitor the chain for status updates.
A simulation API that dry-runs raw transactions on EVM and SVM chains before they are sent.
A gas estimation API for EVM, SVM and TVM chains, so fees are known up front.
If the same transaction request arrives again, it is never executed twice.
Every transaction status change is captured and published to the services that depend on it.
04 / toolbox
05 / work
A telemedicine platform my team built at the BRAC University National Hackathon 2021, placing in the top 5: doctor availability and booking, live video consultations, online prescriptions and a medicine database.
A remuneration management system. I did the backend and database design, using Entity Framework and token-based authentication.
I did competitive programming at university and mentored juniors in DSA. Now I solve problems for fun.
06 / education
Shahjalal University of Science and Technology (SUST), Sylhet
Jan 2019 — Jan 2024 · CGPA 3.76 / 4.00
07 / contact
Based in Dhaka (UTC+6), open to remote and hybrid Go backend roles. Email is the best way to reach me.