HarshaMadusanka
I'm a backend engineer who designs solutions around the problem, not the trend. I think it through before I build, keep things as simple as the problem allows, and lay foundations solid enough to scale when it actually matters.
- [ 01 ]Experience
- 4+ yrs
- shipping software
- [ 02 ]Delivered
- 6+
- production systems
- [ 03 ]Reach
- 30K+
- people rely on it
- [ 04 ]Based in
- Colombo
- Sri Lanka · GMT +5:30
- System design✦
- Distributed systems✦
- Cloud-native✦
- Backend engineering✦
- Reliability✦
- Platform tooling✦
Background.
I understand a problem before I solve it. I'd rather spend an hour at the whiteboard than a week rebuilding, so I work through the constraints, the data, and the ways things break, then design the smallest solution that actually holds up. A solid foundation beats a clever one every time: get that right and you can grow almost anything on top of it.
Most of system design is trade-offs. The best solution on paper is rarely the right one today, so I weigh scale against reliability, maintainability, cost, and the maturity of the team that has to live with it, then choose the path that fits the moment without boxing in what comes next. That judgment is what I bring to the systems I design, the solutions I shape with clients, and the production bugs I chase down, while turning fuzzy requirements into things that ship and bringing the engineers around me along the way.
Currently
Software Engineer
Rooster Technologies, HR + payroll SaaS
BSc (Hons) Computer Science
University of Westminster
Open to
Senior, platform-leaning backend roles
How I approach a system.
A general process, not a fixed stack. Start from the problem, pick the right tool for its shape, and build something that stays calm in production. Scroll to walk it top to bottom.
01 / Start here
Understand the problem before the tech
I get clear on the real constraints first: traffic shape, data volume, failure modes, and what 'good enough' actually means for this team. The tool comes after that, never before.
02 / Choose the tool
Match the pattern to the problem
Most things want a simple, well-factored service. Some want a queue, a cache, or a read replica. I reach for event-driven design only when load is genuinely spiky or the work is truly async, never as a reflex.
03 / Build
Keep the common path simple
The everyday request path stays small, predictable, and fast. Complexity earns its place at the edges where it's actually needed, instead of getting smeared across every service.
04 / Resilience
Assume things will fail
Networks blip, downstreams crawl, deploys go sideways. I design so a failure becomes a retry or a little latency instead of an outage, with idempotency and backpressure where they earn their keep.
05 / Operate
Make it observable
You can't fix what you can't see. Structured logs, metrics, and traces go in from day one, so trouble shows up on a dashboard before a single user feels it.
06 / Sustain
Optimise for the next engineer
Code gets read far more than it gets written. I favour clear boundaries, honest docs, and patterns the team can extend long after I have left the room.
Work history.
Impact first: what got built, the scale it ran at, and the problems it actually solved.
Software Engineer
Rooster Technologies Pvt Ltd
ATS + HRIS cloud-native software
Concurrent users at peak load
Microservices on shared platform library
Faster resume screening pipeline
- Migrated a legacy time-tracking system to a Kafka-based event-driven architecture, scaling to 10,000+ concurrent users without downtime and eliminating the crashes that hit during peak clock-in traffic.
- Designed denormalized reporting models and ETL pipelines, removing expensive runtime aggregations and cutting CPU and memory consumption across the primary service.
- Laid the architectural foundation for a new time-tracking microservice, defining backend standards, data contracts, and event schemas for the team to build on.
- Designed and implemented role-based access control across services and UIs, aligning authorization with domain boundaries.
- Built a shared NestJS / TypeScript library backed by AWS SSM that standardized configuration across 30+ microservices.
- Integrated AI-assisted resume evaluation into internal recruitment workflows with custom reasoning logic and background pipelines, cutting screening time by 60%.
- Contributed to architecture reviews, mentored junior engineers, and helped shape long-term platform evolution.
A few projects I am proud of.
Engineering case studies. Employer and customers stay anonymous.
The toolbox.
What I reach for, grouped by where it lives in the stack.
Languages & Frameworks
13 tools- TypeScript
- JavaScript
- Java
- Node.js
- NestJS
- Express.js
- React
- Next.js
- Spring
- C / C++
- Python
- Django
- Flask
Architecture & Design
04 tools- Microservices
- Event-Driven Architecture
- Domain-Driven Design
- Test-Driven Development
Data Stores, Caching, Search
08 tools- PostgreSQL
- MariaDB
- MongoDB
- DynamoDB
- Redis
- Elasticsearch
- TypeORM
- Prisma
Messaging, Streaming, Observability
05 tools- Apache Kafka
- AWS SQS / SNS
- ELK Stack
- Prometheus
- Grafana
Cloud & Infrastructure
09 tools- AWS EKS
- AWS ECS
- AWS ECR
- AWS EC2
- AWS Lambda
- AWS MSK
- AWS S3
- Terraform
- CloudFormation
DevOps, CI / CD, Platform
06 tools- Docker
- Kubernetes
- GitHub Actions
- Bitbucket Pipelines
- AWS CodeBuild
- AWS CodePipeline
Testing & Reliability
04 tools- Jest
- Mocha
- Supertest
- TDD
AI & Intelligent Systems
03 tools- LLM API integration
- OpenAI
- AI-assisted automation
Let's build the right thing.
Open to senior and platform-leaning backend roles. Remote-friendly across most timezones.