Deep dive into every number on the resume — how it was measured, what it means operationally, and how to defend it in an interview.
Percentile latency means: 95% of all requests complete within this time. P50 = median (half faster, half slower). P99 = worst 1%.
Q: Why did you choose P95 as your SLA target?
A: P95 captures the experience for 95% of users. In a commerce platform, that's what determines perceived reliability. P99 optimization often hits diminishing returns — you're chasing GC pauses or cold DB connections that cost 10x the infra. P95 is where business impact lives.
1. MongoDB connection pooling (Mongoose): Pool size of 10-20 connections, kept warm. Cold connection overhead is 5-30ms per request — eliminated with pooling.
// mongoose connection pool config
mongoose.connect(MONGO_URI, {
maxPoolSize: 20, // max concurrent connections
minPoolSize: 5, // keep warm connections
serverSelectionTimeoutMS: 5000,
socketTimeoutMS: 45000,
});2. MongoDB compound indexes: Every query that filters + sorts has a covering index. Without indexes, a 80K-document collection scan takes 200-500ms. With indexes, <5ms.
// Example: order listing by store + status + date
db.orders.createIndex({ storeId: 1, status: 1, createdAt: -1 });
// Geospatial for <100ms radius search
db.stores.createIndex({ location: "2dsphere" });3. Redis caching hot reads: Store catalog, user sessions, and rate limit buckets hit Redis first. Redis P99 latency ≈ 0.1-1ms vs MongoDB P99 ≈ 5-50ms.
4. Response payload discipline: Use MongoDB projections — never send entire documents. Each saved field = fewer bytes = faster serialization.
// BAD: sends entire product doc (5KB+)
const products = await Product.find({ storeId });
// GOOD: project only needed fields
const products = await Product.find(
{ storeId },
{ name: 1, price: 1, imageUrl: 1, stock: 1 }
);Three approaches, from simple to production-grade:
// 1. Express middleware (custom, zero-cost)
app.use((req, res, next) => {
const start = process.hrtime.bigint();
res.on('finish', () => {
const ms = Number(process.hrtime.bigint() - start) / 1e6;
// Push to a histogram or log for percentile calculation
metrics.histogram('http_request_duration_ms', ms, {
method: req.method,
route: req.route?.path,
status: res.statusCode,
});
});
next();
});
// 2. MongoDB explain() — check query plan
db.orders.find({ storeId: "abc" }).explain("executionStats");
// Look for: executionTimeMillis, totalDocsExamined vs nReturned
// If docsExamined >> nReturned → missing index
// 3. APM (Datadog/New Relic) — production standard
// dd-trace auto-instruments Express, MongoDB, Redis
const tracer = require('dd-trace').init();Q: How do you know it was actually <200ms P95?
A: We instrumented every request with Express middleware logging response time with process.hrtime.bigint() for nanosecond precision, pushed to structured logs, and computed percentiles via MongoDB aggregation on our analytics collection. During traffic spikes we'd check the P95 in real-time. MongoDB's explain("executionStats") told us when we had slow queries that needed indexing.
--watch + AWS ALB health checks auto-replace unhealthy instancesEvery order lifecycle event emits an analytics document to MongoDB. GMV is a MongoDB aggregation on completed orders:
// GMV aggregation
db.orders.aggregate([
{ $match: { status: "COMPLETED", storeId: { $in: storeIds } } },
{ $group: {
_id: null,
totalGMV: { $sum: "$totalAmount" },
orderCount: { $sum: 1 },
}},
]);status != CANCELLEDtotalAmount for completed orders (Gross Merchandise Value = before platform fee deduction)Q: GMV vs Revenue — what's the difference?
A: GMV (Gross Merchandise Value) is the total value of orders processed — what customers paid. Revenue is what the platform earns after paying stores/riders. For a hyperlocal commerce platform, GMV is the most meaningful scale metric because it shows total economic throughput. ₹1.5Cr GMV at a typical 3-5% platform take rate = ₹4.5–7.5L actual revenue.
// Schema: GeoJSON Point
const StoreSchema = new Schema({
location: {
type: { type: String, enum: ['Point'], default: 'Point' },
coordinates: [Number], // [longitude, latitude]
},
});
StoreSchema.index({ location: '2dsphere' });
// Query: stores within 5km radius
const nearbyStores = await Store.find({
location: {
$near: {
$geometry: { type: 'Point', coordinates: [lng, lat] },
$maxDistance: 5000, // meters
},
},
isActive: true,
tenantId: req.user.tenantId,
}).limit(20);Without the 2dsphere index, this query scans every document and computes haversine distance — O(n). With the index, MongoDB uses a geohash-based B-tree that narrows candidates to a tiny subset first — O(log n). At 30 stores, this means 1-2ms query time. Under load: <100ms including network overhead.
Each stage adds a timestamp header to the Kafka message. The final consumer computes finalTimestamp - ingressTimestamp. Snappy compression reduces message size by ~40%, cutting serialization + network time per hop.
Q: Kafka isn't typically known for <50ms latency. How did you achieve it?
A: Three factors: (1) All services run in the same Docker network on OCI, so inter-service network latency is sub-millisecond. (2) Each consumer uses manual offset commit after processing, not auto-commit with a 5s interval — this avoids processing delay from commit batching. (3) Snappy compression cuts the payload, reducing serialization time per hop. The 4-stage pipeline adds roughly 5-15ms per stage, totaling <50ms end-to-end.
For a Node.js/Express single instance (t3.medium, 2 vCPU, 4GB RAM):
Auto-scaling group adds instances at 60% CPU, providing headroom before degradation. At 80K orders (Aug 2022 – Mar 2025, ~32 months), the average rate is ~83 orders/day, not a high-frequency trading system — real peak load was evening delivery windows.