TechFour Engineering Solutions · May, Jul 2025 · Software Engineering Intern
Reusable Backend Microservices
TechFour is a software company of over a hundred people, and it had noticed a pattern: every new project rebuilt the same foundations from scratch. Login, OTP, password reset, file upload, notifications. My internship was to build those once as standalone services with clean APIs, so future projects could pull them in instead of writing them again. There was no external client. The customer was the company's own future codebases.
01Three services, built to be reused
The user management service handles registration, JWT authentication with bcrypt hashing, OTP verification and password reset. The document service handles uploads with metadata validation, date-based organisation and lifecycle management behind an admin view. The communication service sends internal notifications out through WhatsApp and email integrations, with a cron scheduler for anything time-triggered. MySQL with connection pooling underneath, Flask on top.
Designing for reuse changes the work. Each service had to stand on its own, with no assumptions about the app calling it, which meant thinking harder about API surface than I would have for a one-off feature. I also built Flutter web clients against them, which was the fastest way to find out where an API was awkward to consume.
02The process around the code
This was my first exposure to engineering process as something deliberate rather than incidental. Work was tracked in Jira. The company had written policies for branch naming, commit messages and branching strategy, and code went through GitLab on a self-hosted instance. Every endpoint was documented in OpenAPI and served through Swagger UI as it was built, not afterwards, which quietly improved the endpoints themselves.
Quality gates ran through SonarQube with SonarScanner, self-hosted alongside the project. It checks for bugs, code smells and security vulnerabilities, and I kept working through its findings until the services came back clean. Watching a tool flag things I was pleased with is a useful corrective early on.
03Learning deployment from the person who ran it
The most valuable part of this internship was where I happened to sit. My desk was next to Sahil Bhoyar, who ran the company's GitLab, infrastructure and deployments. For about a month he taught me something most days: Linux fundamentals, Nginx, reverse proxying, load balancing, how deployments actually reach a server. He would give me something to read up on, then later show me that exact thing running in the production environment.
That is a kind of knowledge that is hard to get from a course, because the interesting parts are the operational details nobody writes down. It is also why deployment and infrastructure stopped feeling like someone else's job to me.
next article
RAG Assistant over Internal Knowledge →