With more than 73 million users in Japan (as of March 2026) and billions of transactions processed annually, PayPay operates at a scale where engineering decisions — from live data migrations to high-traffic authentication systems — carry real consequences. To strengthen and evolve this technical foundation, PayPay India was established in 2022. In a short period of time, the India hub has grown into a critical development center within the PayPay Group.
In this edition of India Dev Speaks, five engineers from PayPay India’s P2P and User Module teams share how they think as engineers in such an environment. Working alongside Japan-based partner teams, they describe how they make decisions, evaluate trade-offs, respond to failure, and grow through the responsibility they carry within clearly defined project scopes. This is not a story about org structures or reporting lines. It is a conversation about engineering mindset — choosing what to optimize for, deciding which risks to carry, learning from what breaks, and standing by those decisions when they unfold in production.
Meet the Engineers
Tushar:
I joined PayPay India about a year and a half ago and have been part of the P2P team ever since. I’ve owned multiple integration initiatives within the P2P domain.
Sajal:
For the past year and a half, I’ve been working in the P2P team. Most recently, I drove the fraud reporting system — building the backend that handles fraud cases and routes them to the appropriate systems.
Sahil:
I’ve been with the User Module team for about a year and a half, focusing on authentication and core platform capabilities.
Nitin:
Over the last two and a half years at PayPay India, I’ve worked across teams. I recently moved to the User Module team, where I focus on resiliency and system availability. Before that, I built platforms for large-scale gift voucher campaigns in the Merchant Engagement Solutions team.
Aman:
Over the past two years, I’ve worked across multiple domains at PayPay India — from GenAI to Payments to Points. I’m currently part of the P2P team working on large-scale integrations and contributing to how our systems scale under growing traffic.
Working Without Proximity and How Ownership Changes
When you moved from a co-located team to a cross-region setup, what changed?
Tushar:
When I joined PayPay India about a year and a half ago, I was one of the first engineers working in this cross-region setup for P2P. At the beginning, there was a senior engineer from Japan who had relocated to India. He was my go-to person because he had deep knowledge of the P2P system. After that, I had to rely entirely on shared channels and online communication. Once I started reaching out through common team channels, responses were quick. Reviews didn’t get delayed. But I had to be much more deliberate.
Sahil:
In India, we often solve things by pulling someone into a room and drawing on a whiteboard. In cross-region work, especially with Japan-based partner teams, everything needs to be structured and documented.
I remember in one of my early projects, we got stuck because no one was finalizing a technical direction. My instinct was to schedule more meetings. That didn’t work. I started writing detailed design documents, explaining options with diagrams and explicitly calling out trade-offs. Once the document was clear, decisions moved.
Nitin:
Written communication becomes critical. In a co-located setup, context is implicit. Here, you must make context explicit. Before a discussion, you define the problem clearly, outline constraints, and propose a direction. Alignment doesn’t happen organically. It’s intentional.
Aman:
I’ve worked in both co-located and cross-region setups within PayPay. From an engineering culture perspective, I didn’t see a fundamental difference. PayPay Japan is remote-first, and asynchronous communication is normal. The difference is in responsibility. When there’s a time gap, you can’t wait for every confirmation. You think through the problem, make a call within your defined scope, and then align.
Sahil:
We prioritize overlap hours — mornings in India, evenings in Japan. But outside that window, work still needs to move. That’s where ownership becomes visible. If you hesitate, progress slows for everyone.
Nitin:
The teams are distributed. The responsibility isn’t.
What Changes When You Build for 70 Million Users
Looking back, what changed in you as an engineer?
Sajal:
Before joining PayPay, I worked on systems used by a much smaller number of users. Moving to a platform serving more than 70 million users wasn’t just a scale change — it was a responsibility shift. I started thinking differently about quality and scalability. Every change can ripple across multiple services — PayPay Bank, PayPay Securities, and other group entities. A single line of code can have wider impact than you expect. The depth of reviews and discussions here exposed gaps in my thinking. That process didn’t just improve my code — it expanded the way I approach system design.
Nitin:
In the Merchant Engagement Solutions team, my first major responsibility was acting as a tech owner for configurable campaign systems. Being a tech owner meant more than writing design documents. It meant driving consensus and removing blockers. At that time, scale was manageable. Consistency and strict SLAs mattered most. Latency wasn’t a major constraint.
When I moved to the User Module team, the priorities shifted. Traffic volume and latency became central concerns. I once received feedback that a design would not survive traffic under real load conditions. It wasn’t about syntax — it was about how the system behaves at scale. That changed how I approach architecture. I started designing not just for correctness, but for stability under pressure.
Tushar:
I didn’t come from a fintech or Java-heavy background. Understanding how money transfer systems work was a steep learning curve. It looks simple from the outside, but there are layers of validation, safeguards, and risk controls behind every transaction. Reviews here are systematic, especially for anything involving money movement. At first, it felt strict. Over time, I realized that this rigor builds confidence before production release. You don’t just ship features — you protect trust.
Aman:
It’s hard to reduce it to one word, but what changed for me was how I see responsibility. Earlier in my career, speed was the main driver — ship fast and iterate. Here, speed still matters, but you also think about rollback strategies, observability, long-term maintainability, and knowledge transfer. Documentation isn’t just process — it’s part of engineering design. I never felt like a secondary contributor. I was given ownership and expected to justify my decisions. That expectation expanded the scope of what I’m responsible for — and accelerated how I grow as an engineer.
What You Optimize When Everything Matters
When everything is critical, what do you optimize for?
Sahil:
When our Redis version was deprecated, I knew it wouldn’t be a simple upgrade. This cluster stores critical data such as session tokens, and any failure could have had a significant impact on user logins. We benchmarked live migration using Riot, a tool that supports snapshot and incremental sync. Under peak write traffic, replication lag kept increasing. That meant we couldn’t guarantee consistency during the migration window.
The migration looked elegant. It wasn’t safe. So we reframed the question: what failure can we tolerate? We introduced dual read and dual write across both clusters, ensuring both environments remained consistent during the transition. API latency increased temporarily, and SLOs were impacted. But session integrity was preserved. We can slow login. We cannot break login. This migration required changes across roughly 17,000 lines of code. Releasing that magnitude of change into production isn’t just a technical challenge — it’s a responsibility decision. We later re-architected parts of the migration flow and parallelized the comparison process, reducing the migration time from nearly three days to around two hours. At this scale, execution time equals exposure. The longer you run in an unstable state, the higher the risk. The hardest part wasn’t the implementation. It was deciding which risk we were willing to carry — and standing by that decision.
Sajal:
In the fraud reporting project, we had a one-month timeline. The initial scope covered only ‘send money’ transactions. But I knew we would eventually need to support request money, split bills, and recurring transfers. So we designed it to be extensible from the start. At this scale, redesigning later is expensive. Anticipating expansion is part of the trade-off.
Aman:
When opinions differ and timelines are tight, we start with customer impact. We deliver the minimum that protects users first. In one case, we had two competing UI designs. Instead of debating endlessly, we ran an A/B test and let data decide. Speed versus certainty is also a trade-off.
Sahil:
At this scale, elegance is secondary. Survivability is not.
What It Takes to Lead Across Borders
What makes cross-region collaboration difficult, and what mindset does it require?
Nitin:
When I joined the multi-tenant project in the User Module team, I was new and had limited context. I proposed a design and received feedback that I initially struggled to understand. It wasn’t about rejecting the idea — it was about trust and scale assumptions. Convincing others required more than technical correctness. It required context.
Most discussions happened asynchronously — threads, document comments. Waiting for feedback can slow iteration. I started organizing short, focused brainstorming sessions — 15 to 30 minutes — just to clarify the intent behind comments. That helped me iterate faster and build trust.
Sahil:
Timezone differences affect rhythm. A release at 10 p.m. JST is manageable from India, but late for Japan-based teammates. Communication becomes scheduled rather than spontaneous. If only one or two people understand a critical component, knowledge transfer takes longer. That’s why being a self-starter matters. You cannot depend on someone always being available. You think through the problem, document clearly, use structured templates, and move. Overcommunication isn’t excessive here — it’s necessary.
Nitin:
Team bonding is different too. When you’re not co-located, relationships don’t form automatically. Sometimes we join standups a few minutes early and talk about sports or daily life. It sounds small, but it helps build familiarity.
Aman:
Cross-region setups are not for everyone. If you hesitate to take ownership, this environment will feel uncomfortable. Nobody micromanages you, but nobody absorbs your responsibility either. Ownership drives growth. The more responsibility you carry, the faster you evolve.
Nitin:
Adapting to different communication styles is also important. If you misinterpret silence as agreement, you’ll move in the wrong direction. Alignment must be explicit.
Sahil:
In the end, distributed collaboration accelerates maturity. You don’t just write code. You think independently, communicate deliberately, and stand by your decisions — even when your teammates are in another country.
Growth and What Comes Next
How does your career evolve in this environment?
Sajal:
PayPay India is not limited to building a payment app. We work across PayPay Card, PayPay Bank and multiple group entities. When I joined, I focused mainly on implementation. Over time, my role expanded — from writing code to thinking about system design, reviewing others’ work, and understanding how different components interact. Growth here means expanding the scope of responsibility you’re willing to carry.
Aman:
Earlier in my career, speed was the primary metric. Here, speed still matters, but so do dependency handling, state consistency, observability, metrics, and rollback strategies. You design with failure in mind. Growth, for me, has meant increasing the number of factors I consider before making a decision.
Sahil:
As my role has evolved, I’ve started thinking beyond individual features. I’m now focused on system-level improvements, such as reducing maintenance downtime as close to zero as possible through live upgrades. Integrating AI more deeply into development is also part of that shift — not just as a tool, but as part of how we design systems.
Nitin:
Earlier in my career, I focused on individual components. Now, my perspective has expanded toward platform-level architecture. Unifying shared capabilities across group companies reflects how my scope has grown — from feature ownership to system-wide thinking.
For Engineers Ready to Take Ownership
Who thrives here, and why it’s worth it?
Aman:
If you’re looking to simply complete assigned tasks, this environment may feel heavy. The engineers who thrive here think beyond the ticket — about scalability, failure scenarios, long-term maintainability, and production reliability. If you want to define trade-offs and see your decisions tested under real traffic, this is the kind of place that challenges you.
Tushar:
Curiosity matters. You’re exposed to payments, banking, securities — not just one isolated system. If you want to understand how large-scale financial systems truly operate, you’ll learn fast.
Nitin:
You also need to be comfortable with risk. I’ve worked on projects where I faced high-stakes situations in production. What defines you is not whether something breaks — it’s how you analyze it, fix it, and redesign it so it doesn’t break the same way again.
Sahil:
No one spoon-feeds you. But you’re trusted with ownership. That trust forces you to level up. Seeing something you designed run under real production traffic — that’s deeply rewarding.
Sajal:
When we launched the fraud reporting feature, adoption exceeded expectations. Seeing real users interact with something you built at this scale — that’s exciting. It reminds you why responsibility matters.
Nitin:
You don’t just write code here. You take responsibility for outcomes. If that excites you more than it intimidates you, you’ll grow significantly in this environment.
*Information such as job openings and employee affiliations is accurate as of the time of the interview.
