Introduction
Most developers understand the individual technologies they work with:
- ReactJS
- API Gateway
- Spring Boot
- Node.js
- Kafka
- Redis
- PostgreSQL
- Kubernetes
However, very few understand what actually happens when a user clicks a button.
A modern application is not a collection of frameworks.
It is a distributed system.
The real challenge is not understanding React, Spring Boot, or Kafka independently.
The challenge is understanding how they interact under real-world conditions involving:
- Latency
- Security
- Failures
- Retries
- Scaling
- Observability
- Consistency
In this article, we will follow a single request from a user's browser all the way to a committed database transaction and back.
Scenario
Consider a healthcare platform.
A member updates their address.
The user clicks:
Save Address
Simple.
Or so it appears.
Step 1: React Fiber Begins Work
When the user clicks:
<button onClick={saveAddress}>
Save
</button>
React does not immediately update the UI.
The event enters React's scheduling system.
Why React Fiber Exists
Before Fiber:
Large UI Update
↓
Blocks Browser
After Fiber:
Large UI Update
↓
Break Into Units
↓
Schedule Efficiently
Benefits:
- Better responsiveness
- Reduced UI freezes
- Concurrent rendering
Step 2: API Request Construction
The browser prepares:
POST /api/member/address
Authorization: Bearer JWT
Content-Type: application/json
Payload:
{
"memberId": 123,
"address": "New Address"
}
Step 3: Browser Security Checks
Before reaching the backend:
- HTTPS Validation
- Certificate Verification
- CORS Validation
- DNS Resolution
Potential failures:
DNS Failure
TLS Failure
CORS Failure
Request never reaches the application.
Step 4: API Gateway
Architecture:
React
↓
API Gateway
Responsibilities:
- Authentication
- Rate Limiting
- Routing
- Logging
- WAF Protection
Example:
Azure APIM
AWS API Gateway
Kong
NGINX
Why API Gateways Matter
Without Gateway:
Client
↓
50 Services
With Gateway:
Client
↓
Gateway
↓
Services
Benefits:
- Simplified access
- Centralized security
Step 5: JWT Validation
The gateway validates:
Signature
Issuer
Audience
Expiration
Many developers mistakenly trust:
{
"role":"ADMIN"
}
inside the JWT payload.
Only verified tokens should be trusted.
Step 6: Load Balancer Routing
Request enters:
AKS
EKS
App Service
ECS
Load balancer selects:
Instance #7
How Routing Actually Works
Common algorithms:
- Round Robin
- Least Connections
- Weighted Routing
This determines which container receives the request.
Step 7: Spring Boot Request Lifecycle
Request enters:
Security Filter
↓
Controller
↓
Service
↓
Repository
Example:
@PostMapping("/address")
Controller should remain thin.
Business logic belongs elsewhere.
Step 8: Validation Layer
Before processing:
@NotNull
@NotBlank
@Size
Validation failures return:
400 Bad Request
early.
Fail fast.
Step 9: Business Service Layer
Now actual business logic begins.
Example:
updateAddress()
Responsibilities:
- Business Rules
- Authorization Checks
- Data Transformation
Step 10: Cache Lookup
Before database access:
Redis
may be checked.
Flow:
Request
↓
Redis
↓
Database
Benefits:
- Reduced latency
- Lower database load
Step 11: Database Transaction
Transaction begins:
@Transactional
Spring creates:
Database Session
and acquires connections from:
HikariCP
Hidden Complexity
Developers often forget:
Connection Pools
Locking
Isolation Levels
Indexes
Execution Plans
all affect performance.
Step 12: Event Publication
Address update succeeds.
System publishes:
AddressUpdated
event.
Why Events Matter
Without Events:
Address Service
↓
Email Service
↓
Audit Service
↓
Analytics Service
Tight coupling.
With Events:
AddressUpdated Event
↓
Kafka
↓
Consumers
Loose coupling.
Step 13: Kafka Processing
Consumers receive:
{
"event":"AddressUpdated"
}
Possible actions:
- Audit Logging
- Notification
- Analytics
- Synchronization
Step 14: Node.js Worker Processing
A Node.js worker may handle:
AddressUpdated
event.
Why Node?
Excellent:
- Async Processing
- I/O Operations
- Notifications
Step 15: Observability
Throughout the journey:
Metrics are collected.
Examples:
Request Duration
Error Rate
Database Time
Kafka Lag
Redis Hit Ratio
Tools:
- OpenTelemetry
- Prometheus
- Grafana
- CloudWatch
- Azure Monitor
Step 16: Failure Handling
What if database fails?
Possible patterns:
Retry
Retry 3 Times
Circuit Breaker
Open Circuit
using:
Resilience4j
Fallback
Cached Data
returned.
Step 17: Response Journey
Database:
Success
↓
Spring Boot:
200 OK
↓
Gateway
↓
Browser
↓
React State Update
↓
UI Refresh
What the User Sees
User experiences:
Address Saved
within:
300ms
What Actually Happened
Behind those 300ms:
React Fiber
DNS
TLS
Gateway
JWT
Load Balancer
Spring Security
Validation
Business Logic
Redis
Database
Kafka
Observability
Response Rendering
A modern distributed system executed dozens of operations.
Architect's Perspective
The biggest difference between a developer and an architect is not coding ability.
It is systems thinking.
Developers often see:
Controller
↓
Database
Architects see:
User Experience
Network
Security
Scaling
Caching
Transactions
Events
Monitoring
Failure Handling
Operations
simultaneously.
Every request is a journey through an ecosystem rather than a single application.
Conclusion
Modern cloud-native applications are no longer simple request-response systems.
They are distributed ecosystems composed of:
- Frontend Frameworks
- API Gateways
- Authentication Layers
- Microservices
- Event Streams
- Databases
- Observability Platforms
Understanding how a single request travels through this ecosystem provides a deeper understanding of software architecture than learning any framework in isolation.
The strongest engineers do not merely understand technologies.
They understand how technologies collaborate to deliver business value reliably, securely, and at scale.
Comments
Post a Comment