Nikhil Gautam
Software engineer: backend architecture, distributed systems and data-intensive applications.
Engineering background
I’m a software engineer who works mostly on the backend. My experience spans backend services, full-stack work and cloud engineering, but the problems I keep returning to are the ones in the middle of a system: how data moves between components, what happens when a step fails, and how to keep separate stores consistent with each other.
I care about the reasoning behind a design as much as the design itself: which guarantees a system actually provides, which ones it only appears to, and what it costs to close the gap.
Selected experience
Professional work, described without employer or client detail.
Event-driven search
A search platform fed by change data capture: Debezium capturing database changes, Kafka carrying them, and consumers keeping OpenSearch indices, including vector indices, up to date.
Large-volume batch processing
Java and Spring Batch jobs on AWS, working with AWS Batch, S3 and Athena, where retry and failure handling decide whether a failed run can simply be restarted.
Service architecture and performance
Migrating from a monolith towards microservices, and improving backend performance through service boundaries and asynchronous processing.
What I work on
- Backend architecture
- Distributed systems
- Event-driven architecture
- Data-intensive applications
- Microservices
- Performance engineering
- Cloud-native systems
- Reliability and observability
- System design
Technical areas
These are the tools I’ve used, not the definition of the work. The constant across them is the systems thinking.
How I approach systems
Correctness before optimization
Define what “correct” means first: invariants, ordering guarantees, what happens on a retry. An optimization that weakens those properties without saying so isn’t an improvement. It’s a deferred incident.
Reliability is an architectural concern
Retries, timeouts, back-pressure and recovery paths shape a system’s structure. They belong in the design review, not in the post-incident action items.
Distributed systems trade-offs, made explicit
Every boundary between processes forces a choice about consistency, availability and latency. I prefer to name that choice, write down why, and decide what the system does when the assumption breaks.
Observability is part of the design
If a system can’t explain its own behavior in production, it isn’t finished. Useful signals come from asking which questions an on-call engineer will need answered, before the system ships.
Performance grounded in measurement
Profile, then form a hypothesis, then change one thing. Throughput and latency claims without a baseline and a method are opinions.