A deep dive into how DNS, Load Balancers, Ingress, Services, kube-proxy, CNI, Pods, Secrets, Databases, Autoscaling, and Observability work together to process a single payment.
1. The User Taps "Pay"
A customer opens the PhonePe app and sends ₹1000.
Mobile App
|
POST /payment
At this moment Kubernetes hasn't seen the request yet.
2. DNS Finds the Application
The phone asks:
Where is api.phonepe.com?
DNS responds with the public IP of the Load Balancer.
|Mobile`
|
DNS
|
Load Balancer IP
3. The Load Balancer Receives Traffic
The cloud Load Balancer becomes the entry gate.
Internet
|
Load Balancer
Responsibilities:
SSL/TLS termination
Traffic distribution
DDoS protection
High availability
4. Ingress Becomes the Traffic Police
The request enters Kubernetes.
Load Balancer
|
Ingress Controller
Ingress examines:
Http
POST /payment
and decides:
Send traffic to payment-service
5. Service Finds the Right Application
A Kubernetes Service acts like a stable virtual address.
Ingress
|
payment-service
Users never talk directly to pods.
Pods come and go.
Services remain stable.
6. kube-proxy or eBPF Chooses a Backend Pod
The Service may have:
payment-pod-1
payment-pod-2
payment-pod-3
payment-pod-4
Routing happens through:
Service
|
kube-proxy
or
Service
|
eBPF (Cilium)
One healthy pod is selected.
7. Endpoints Tell Kubernetes Where Pods Exist
Endpoints contain real Pod IPs.
payment-service
|
Endpoints
|
10.0.1.15
10.0.2.20
10.0.3.18
The request is mapped to an actual pod.
8. CNI Moves the Packet Across the Cluster
Now networking begins.
Node A
|
CNI
|
Node B
The CNI plugin:
AWS VPC CNI
Calico
Cilium
ensures the packet reaches the correct pod.
9. Network Policies Check Security Rules
Before reaching the application:
Packet
|
Network Policy
Kubernetes verifies:
Is this traffic allowed?
If not:
DROP
The request never reaches the application.
10. The Payment Pod Processes the Request
The application finally receives:
POST /payment
Business logic starts.
Examples:
User validation
Balance checks
Fraud detection
Payment creation
11. Secrets Provide Sensitive Information
The application needs credentials.
Database Password
UPI Keys
API Tokens
Certificates
These come from Kubernetes Secrets.
12. ConfigMaps Provide Configuration
The application also needs:
Timeouts
Feature Flags
Log Levels
These come from ConfigMaps.
13. Internal Microservices Communicate
The payment service rarely works alone.
It may call:
User Service
Fraud Service
Notification Service
UPI Service
Each call again passes through:
Service
|
kube-proxy/eBPF
|
Pod
14. Database Stores the Transaction
Payment information is persisted.
Payment Pod
|
Database
Examples:
PostgreSQL
MySQL
Cassandra
MongoDB
The transaction record is saved.
15. Persistent Volumes Protect Data
Data is stored on:
Persistent Volume
through:
Persistent Volume Claim
Even if pods die, data survives.
16. Observability Captures Metrics
While the payment is being processed:
Latency
Request Count
Error Rate
CPU Usage
Memory Usage
are collected.
Typical stack:
Prometheus
|
Grafana
17. Logging Records Every Event
Every action creates logs.
Payment Started
Payment Approved
Payment Completed
These logs help engineers troubleshoot problems.
18. Health Probes Continuously Check the Application
Kubernetes performs:
Startup Probe
Readiness Probe
Liveness Probe
to ensure the service remains healthy.
19. Horizontal Pod Autoscaler Handles Traffic Spikes
Suppose a festival sale begins.
Traffic jumps from:
100 Requests/sec
to
10000 Requests/sec
HPA responds:
Plain text
4 Pods
↓
20 Pods
↓
100 Pods
automatically.
20. Scheduler Places New Pods
Every new pod requires a node.
The Scheduler decides:
Which node should run this pod?
based on:
CPU
Memory
Affinity
Taints
Tolerations
21. Kubelet Starts Containers
After scheduling:
Scheduler
|
Node
|
Kubelet
Kubelet ensures the container is running.
22. Container Runtime Launches the Application
The runtime:
containerd
pulls the image and starts the application.
payment:v1
23. Deployment Maintains Desired State
If a pod crashes:
Desired Pods = 10
Current Pods = 9
Deployment immediately creates a replacement.
24. Cluster Autoscaler Adds More Nodes
When the cluster runs out of capacity:
No Space Available
Cluster Autoscaler or Karpenter provisions additional nodes.
10 Nodes
↓
20 Nodes
"25. The Response Returns to the User*
Finally:
Payment Successful
Transaction ID: TXN12345
travels back through:
Pod
|
Service
|
Ingress
|
Load Balancer
|
Internet
|
Mobile App
The user sees:
₹1000 Paid Successfully
Final Architecture:
User
|
DNS
|
Load Balancer
|
Ingress
|
Service
|
kube-proxy/eBPF
|
Endpoints
|
CNI
|
Network Policy
|
Pod
|
Secrets + ConfigMaps
|
Microservices
|
Database
|
PV/PVC
|
Response
|
Microservices
|
Database
|
PV/PVC
|
Response
Closing Thought
A payment that takes less than a second on your phone triggers an entire Kubernetes ecosystem behind the scenes—networking, security, service discovery, routing, storage, autoscaling, observability, scheduling, and self-healing—all working together to process a single transaction reliably
Top comments (2)
Excellent explanation..!!
Very Insightful