DSA Questions

1. Removing Stars From a String

• Outcome: I was able to solve this optimally with a Time Complexity of O(n) and a Space Complexity of O(n).

2. Longest Palindromic Substring

• Approach: I provided a solution with a Time Complexity of O(n³) and a Space Complexity of O(1), which was not optimized at all.

• Outcome: I wasn’t able to solve this one. I started with a completely wrong approach, and the interviewer’s hints unfortunately threw me even further off the mark.

System Design Round (The Culprit Discussion)

This is where things got tough. Here is what we discussed:

• An introduction to my current project.

• Which AWS services I have hands-on experience working with.

• How deployment works in my current organization.

• How I would improve a database containing 10 million records without making architecture-level changes.

• Why I chose ECS for my current project instead of other available services.

• How to scale the delivery of 500KB images for 40,000 users.

• Identifying what components are likely to break when handling large-scale traffic in my project.

• A discussion on PDF Puppeteer and why it failed.

• An explanation of the SOLID principles.

• The Singleton Design Pattern and its practical use cases.

• How to design a website to handle read-heavy database operations.

Since it was a Cloud Platform team, they were specifically looking for someone with strong Kubernetes and containerisation experience.

The biggest lesson I learned? Take System Design preparation very seriously.

Chalo bye. Aage dekhte hai!

Input: height = [0,2,0,3,1,0,1,3,2,1]

Output: 9

Recommended Time & Space Complexity
You should aim for a solution as good or better than O(n) time and O(n) space, where n is the size of the input array.

Brute Force Approach :

For each index i, calculate the maximum left and right walls to find the trapped water.

Time Complexity : O(N^2)

Space Complexity : O(1)

Suffix and Prefix Array :

In this approach, we will maintain two arrays to precompute the maximum heights:

• Prefix Array (leftMax): This array will store the highest wall encountered from the left side up to each element. Specifically, leftMax[i] represents the maximum height from index 0 to i.

• Suffix Array (rightMax): This array will store the highest wall encountered from the right side up to each element. Specifically, rightMax[i] represents the maximum height from index i to the end of the array (n - 1).

public class Solution {
    public int trap(int[] height) {
        int n = height.length;
        if (n == 0) {
            return 0;
        }

        int[] leftMax = new int[n];
        int[] rightMax = new int[n];

        leftMax[0] = height[0];
        for (int i = 1; i < n; i++) {
            leftMax[i] = Math.max(leftMax[i - 1], height[i]);
        }

        rightMax[n - 1] = height[n - 1];
        for (int i = n - 2; i >= 0; i--) {
            rightMax[i] = Math.max(rightMax[i + 1], height[i]);
        }

        int res = 0;
        for (int i = 0; i < n; i++) {
            res += Math.min(leftMax[i], rightMax[i]) - height[i];
        }
        return res;
    }
}
// Time Complexity - O(n)
// Space Complexity - O(2n)

Two Pointer Approach :

Intuition behind this : Water at any position depends on the shorter wall between the left and right sides. So if the left wall is shorter, the right wall can't help us—water is limited by the left side.
That means we safely move the left pointer inward and calculate how much water can be trapped there.
Similarly, if the right wall is shorter, we move the right pointer left.

public class Solution {
    public int trap(int[] height) {
        if (height == null || height.length == 0) {
            return 0;
        }
        int l = 0, r = height.length - 1;
        int leftMax = height[l], rightMax = height[r];
        int res = 0;
        while (l < r) {
            if (leftMax < rightMax) {
                res += leftMax - height[l];
                l++;
                leftMax = Math.max(leftMax, height[l]);
            } else {
                res += rightMax - height[r];
                r--;
                rightMax = Math.max(rightMax, height[r]);
            }
        }
        return res;
    }
}
// Time Complexity - O(n)
// Space Complexity - O(1)

My Preparation Strategy

To get interview-ready, my core focus was on building strong problem-solving fundamentals:

• Neetcode 150 Questions: An essential list for mastering algorithmic patterns.

• Java Basics: Deep diving into the language fundamentals.

• Object-Oriented Programming (OOPs): Crucial for writing clean, structured code.

The Interview Format

Each technical round lasted exactly one hour and followed a rigorous, two-step format:

1. White-boarding: First, I had to write out the most optimal solution on paper.

2. Live Coding: Next, I had to type that exact same logic into a LeetCode-style editor.

Round 1: DSA

This round tested foundational data structures and array manipulation.

• Q1: Min Stack

• Q2: Capacity to Ship Packages Within D Days

Round 2: DSA

This round shifted focus to searching algorithms and standard data structure design.

• Q1: First Bad Version

• Q2: LRU Cache
  

Additional Practice Questions

Based on my experience, KPMG usually focuses on the easy-to-medium difficulty range. Here are a few more standard problems that are highly relevant for your preparation:

• Course Schedule

• Symmetric Tree

• Valid Parentheses

Up Next: The Client Interview round in Part 2 : ComingSoon
If this guide helped your prep, drop a like and subscribe so you don't miss it. 🤍

1. Writing Policies

2. Eviction Policies

3. Cache Invalidation

4. Sharding in Cache Clusters
   

WRITING POLICY

1. Write Through → Synchronously write to cache and DB to make sure data remains consistent between them .

   1. a pros → Data Consistency , No Stale Data

   2. b cons → Latency in Write , Write heavy system might be laggy /slow .

2. Write Back → Write to Cache and Asychronously flushed the changes to DB .

   1. Pros → Low Write Latency

   2. Cons → Data Loss in case of Cache Crashed Just Before Flushing to DB. Temporarily Inconsistency as well.

3. Write Around → Write will take place to DB . Then in case of Miss Cache will get the latest Data .

   1. Pros → Low Write Latency , No Data Loss .

   2. Cons → Cache Would contain Stale Data , Data Inconsistency .

EVICTION POLICY

1. Least Recently Used(LRU)

2. Least Frequently Used(LFU)

3. Most Recently Used(MRU)

4. Most Frequently Used(MFU)

5. First In First Out (FIFO)

CACHE INVALIDATION

Time to Live ( TTL )→ For each cache entry a TTL will be asign to each cache Entry . On the expiry of the that Time Limit . The Data in Cache would be considered as expired/InValid data.

1. Active Expiration → A background process periodically scans the cache and removes expired items.

2. Passive Expiration → An item’s TTL is checked only when it is requested. If it has expired, it is removed, and a cache miss is triggered.

Sharding in cache Clusters

1. Dedicated Cache Servers (Distributed Cache)

   1. An independent network service that stores data in RAM across a cluster of separate, dedicated machines. It provides a centralized, shared caching layer decoupled from the application, allowing any application server in a distributed system to read and write to a single source of true cached state. (Examples: Redis, Memcached, AWS ElastiCache)

2. Co-Located Cache (Local / In-Process Cache)

   1. A caching mechanism where data is stored directly within the local memory space (heap) of the application process itself. It eliminates network latency by sharing the same host hardware and lifecycle as the application, but limits the cached data to that specific application instance. (Examples: Caffeine, Guava Cache, Python's @lru_cache)

3. Cache Client

   1. A software library embedded within the application that manages connections, serialization, and operations against a cache service. In a distributed caching architecture, the client is responsible for data sharding and topology awareness—using algorithms like consistent hashing to deterministically route PUT and GET requests for a specific key to the correct node in the cache cluster.

   ---

   Next up in this series: Read Design Distributed Cache : Part 2 here Coming Soon

1. High-Level Architecture Overview

To support tens of millions of Daily Active Users (DAU), the architecture is split into decoupled, horizontally scalable microservices. Each component is optimized for a specific domain — whether that is persistent profile storage, high-performance spatial indexing, or rapid write paths for user interactions.

The system relies on an API Gateway acting as the central entry point handling routing, authentication (JWT validation), and rate limiting. Behind it sit three core systems:

• Profile Service: Manages user registration and modifications.

• Discovery Engine: Geographically targets and ranks potential matches.

• Swipe Service: Absorbs the massive firehose of user interactions.

2. The Dual-Database Strategy: Profile Service vs. Discovery Index

A common interview trap is trying to force a single database to handle both regular user management and complex spatial discovery queries. Tinder elegantly solves this by decoupling its data into two specialized layers: DynamoDB (the Source of Truth) and Elasticsearch (the Discovery Index).

DynamoDB — The Source of Truth

The Profile Service writes synchronously to Amazon DynamoDB. Relational databases (SQL) are intentionally avoided here because the system does not require complex ACID transactions, multi-table joins, or foreign keys. Instead, it requires predictable scaling and high-performance key-value lookups.

• Data Structure: Profiles are stored as single documents.

• Access Pattern: When a user requests a profile via GET /profile/{id}, it executes a direct, single-partition point lookup using the userId as the Partition Key (PK). This bypasses expensive table scans entirely.

• TTL & Inactivity: A Time-To-Live (TTL) attribute is assigned to lastHeartbeat. If a user is inactive for more than 24 hours, DynamoDB Streams can catch this event to trigger background reactivation workflows or push notifications.

Elasticsearch — The Discovery Index

Elasticsearch (ES) serves as a specialized, slimmed-down copy of the profile data. It is optimized explicitly for high-velocity filtering and relevance sorting rather than primary data durability.

• Asynchronous Decoupling via Kafka: Writing directly to Elasticsearch from the synchronous profile path is dangerous. If the Elasticsearch cluster undergoes a node failure or experiences a latency spike, the primary Profile Service would degrade. To prevent this, the Profile Service writes updates to a Kafka topic (user.profile.created/updated). An ES Feeder Worker consumes these events asynchronously, buffering the load and ensuring isolation.

3. The Discovery Engine & Spatial Geosharding

When a mobile client calls GET /feed?lat=12.97&lon=77.59&dist=50, the system must search through millions of profiles instantly. Doing a raw SQL-style bounding box filter (SELECT * WHERE distance < 50km) against 50 million active users causes full table scans and completely breaks at scale.

Tinder scales this layer using GeoSharding powered by Google’s open-source S2 Geometry Library.

How S2 Spatial Sharding Works

The S2 library projects the Earth’s sphere onto a flat surface and hierarchically subdivides it into cell structures.

1. Dynamic Cell Sizes: Cell dimensions are mathematically derived based on regional user density, active user counts, and query velocity. Highly populated, high-density metropolitan areas like Mumbai are divided into numerous small cells. Sparsely populated regions, such as the Sahara Desert, are mapped to a single massive cell. This ensures that the overall server compute load remains uniform worldwide.

2. Parallel Fan-Out Queries: When a user requests a feed, the Discovery Engine passes their exact latitude, longitude, and radius parameters into the S2 library. The library calculates and returns a discrete list of intersecting cell IDs that cover that radius.

Rather than hitting a single monolithic database cluster, the system executes a parallel fan-out query across the specific Elasticsearch shards assigned to those exact cell IDs (e.g., Shards A, B, C, and D).

Inside the Elasticsearch Shard: Filter vs. Sort

Once the parallel queries hit the designated geoshards, the search process executes in two distinct phases:

• Phase 1: Filter Context (Hard Exclusions): The engine evaluates rigid Boolean requirements (e.g., geo_distance <= 50km, age between 22-30, interestedIn == "female", moderationStatus == "ok"). This step operates inside a specialized filter context, bypassing relevance scoring. The binary yes/no results are cached inside highly optimized bitsets within memory, resulting in virtually zero recurring execution cost.

• Phase 2: Query Context (Relevance Scoring): Profiles that survive the hard filters pass into the sorting engine. Here, a custom script plugin calculates a floating-point score based on tinder algorithms, incorporating factors like activityScore (primary) and lastActiveAt (recency boost). The top ~25 highest-scoring documents per shard are returned to the Discovery Engine, which merges, de-duplicates, and filters out previously swiped profiles before delivering a final feed of ~20 profiles back to the mobile client in less than 300ms.

4. The Swipe Service: Handling 4 Billion Swipes Daily

The true engineering bottleneck of a major dating application is the write path for user interaction. Consider the core scale metrics:

20M Daily Active Users * 200 swipes/day = 4 Billion swipe writes per day

This volume averages out to roughly 46,000 writes per second, with massive traffic spikes during peak evening windows. The architecture of the Swipe Service is engineered end-to-end to absorb this massive throughput without performance degradation.

The Synchronous Swipe Path

When a user right-swipes, the mobile client executes a POST /swipe/{targetId} call containing the payload { decision: "yes" }. The Swipe Service validates the inbound JSON Web Token (JWT), extracts the swiperId and targetId, and immediately forks the execution path into two distinct concurrent streams:

1. Persistence Layer (Cassandra): The interaction is instantly written to Apache Cassandra. Because Cassandra writes are highly optimized disk appends, this call returns almost immediately. Once the Cassandra log append and in-memory structures acknowledge the write, the system returns a 200 OK HTTP status to the client app. The client does not block or wait for match processing to complete.

2. In-Memory Match Detection (Redis): Concurrently, the service leverages Redis to run ultra-low latency lookups to check if the target user has already liked the swiper.

5. Real-Time Match Detection Using Redis

Querying a persistent disk-based database to evaluate if two users have mutually liked each other is far too slow for real-time engagement. Instead, Redis handles match detection completely in-memory using an elegant key-naming convention.

The Key-Value Lookup Pattern

The system stores swipe states using a highly deterministic string formatting structure: swiperId_targetId. Let's analyze the exact command flow when Person B (id: 456) right-swipes on Person A (id: 123):

Code snippet

SET 456_123 "yes" EX 1209600
GET 123_456

• The system runs a SET command to log Person B's swipe with an explicit 14-day Time-To-Live (TTL) expiration window

• It instantly fires a GET 123_456 command to verify if Person A has an active historical swipe record pointing back to Person B. If the GET command hits an active value, a mutual match is instantly confirmed.

Managing Memory Footprint via TTL

Because memory is highly expensive and holding millions of historical keys indefinitely is unfeasible, the 14-day TTL trade-off is critical. If Person A swiped right on Person B three weeks ago, that key has automatically expired out of memory. If Person B swipes right today, the GET lookup returns a cache miss.

This design choice means no instant match will fire; instead, the interaction falls back onto the background batch processing engine or requires an eventual profile re-encounter, sacrificing absolute edge-case accuracy to maintain an optimized Redis memory footprint.

Eliminating Race Conditions via Atomic Lua Scripts

A prominent system design trap occurs during simultaneous swipes. If Person A and Person B right-swipe each other at the exact same millisecond across different application nodes, a classic race condition emerges:

• Node A Execution: Executes SET A_B, then runs GET B_A. It returns a cache miss because Node B’s write has not yet committed.

• Node B Execution: Executes SET B_A, then runs GET A_B. It also returns a cache miss because Node A’s write was concurrent.

Both operations miss, failing to detect the mutual match in real time. Tinder resolves this by packaging the lookup logic into an atomic Lua Script executed directly inside the single-threaded execution loop of the Redis engine:

Lua

redis.call('SET', KEYS[1], 'yes', 'EX', 1209600)
local inverse = redis.call('GET', KEYS[2])
return inverse

Because Redis guarantees that a Lua script runs as an isolated, atomic block, no separate commands can interleave between the write and the check, entirely eliminating simultaneous race conditions.

As a redundant safety net, a background reconciliation system periodically sweeps historical Cassandra entries to catch any mismatched anomalies and retroactively deliver push notifications to affected users.

6. Storage Deep-Dive: Why Apache Cassandra Dominates Writes

Standard relational database management systems (RDBMS) like MySQL or PostgreSQL fall over under a continuous load of 46,000 writes/second. This failure happens because relational engines utilize B-Tree indexing structures, which require random I/O operations to modify indexes in-place on physical storage media.

Apache Cassandra circumvents this bottleneck by ensuring the physical write path relies entirely on sequential disk append operations.

The Append-Only Log Architecture

Cassandra processes incoming swipe data through a three-stage pipeline:

• CommitLog (Write-Ahead Log): The write request lands on a physical storage node and is appended sequentially to an on-disk CommitLog. Because it acts as a plain sequential append stream, the physical drive head doesn't shift positions, maximizing disk performance. This serves as a durability guarantee if a node suffers sudden power loss.

• MemTable (In-Memory Buffer): The data immediately populates an internal, sorted write-buffer in RAM called the MemTable. Once the data is registered in the MemTable, the database returns a success code to the application layer.

• SSTables (Sorted String Tables): When the MemTable reaches its maximum memory capacity (typically ~32MB), it flushes its sorted contents to disk as an immutable SSTable file. Because SSTables are completely immutable, they are never modified in-place. A background compaction process periodically merges older, separate tables together while filtering out outdated records.

Maximizing Query Speeds via Partitions

Cassandra achieves linear horizontal scalability by hashing data properties across cluster rings using a Partition Key.

Tinder partitions data directly by swiping_user_id. When the application queries the data to check user status (e.g., "Did user_123 swipe on user_A?"), the query hashes the partition ID and routes directly to the single cluster node holding that user's partition block. This completely eliminates expensive cross-node scatter-gather operations, executing reads within sub-millisecond windows.

7. Optimizing Feeds using Bloom Filters

To prevent users from seeing profiles they have already swiped on, the discovery feed generation needs a memory-efficient way to check for past interactions. Rather than scanning Cassandra records for every candidate profile in a feed, the system relies on an in-memory probabilistic data structure: a Bloom Filter.

How the Bloom Filter Works

A Bloom filter represents historical interactions using a bit array of $m$ bits (initially all set to 0) combined with $k$ independent cryptographic hash functions.

• Writing an Interaction: When a user left-swipes or right-swipes a profile (userId = "u_456"), that ID is passed through the $k$ hash functions. Each function outputs a specific index position inside the bit array (e.g., indices 2, 7, and 12). The system flips those specific bits to 1.

• Checking an Interaction: When evaluating whether a candidate profile (u_999) should appear in a user's discovery feed, the system runs the candidate ID through the same hash functions.

• If any of the computed bit locations contain a value of 0, the profile is definitely not seen and can safely be included in the feed.

• If all evaluated bit locations contain a value of 1, the profile is flagged as probably seen and is excluded from the feed.

The Probabilistic Trade-Off

Bloom filters guarantee zero false negatives — if a user swiped on a profile, its corresponding bits are mathematically guaranteed to be set to 1, meaning the user will never accidentally see a profile they already rejected.

While false positives are statistically possible due to rare bit collisions (where separate IDs happen to map to the same set of bits), the trade-off is highly acceptable. At worst, a user misses out on seeing a single candidate profile, which is a negligible cost for a massive reduction in database read operations.

Summary of Architectural Choices

• User Profile Storage: Amazon DynamoDB

• Core Reason: High-performance, schema less document point lookups via userId.

• Discovery Search Engine: Elasticsearch

• Core Reason: Lightning-fast spatial filter caching and dynamic relevance scoring.

• Spatial Indexing: Google S2 Library

• Core Reason: Translates coordinates into discrete cell clusters for parallelized geosharding.

• Data Streaming: Apache Kafka

• Core Reason: Decouples profile updates and swipe match events from execution paths.

• High-Throughput Swipes: Apache Cassandra

• Core Reason: Append-only write path (CommitLog + MemTable) that scales linearly.

• Real-Time Match Engine: Redis + Lua

• Core Reason: Ultra-low latency, in-memory atomic key-value operations.

• Feed Deduplication: Bloom Filters

• Core Reason: Highly space-efficient method to prevent duplicate profile encounters.

• Real-Time Push Alerts: WebSockets + APNS/FCM

• Core Reason: Maintains open connections for matches and background notification routing.

The biggest mistake people make is jumping straight into databases or randomly naming technologies.
Instead, always follow a simple structure.

The Flow to Follow

1. Requirements
2. Estimations
3. High-Level Design
4. Database Design
5. APIs & Data Flow
6. Deep Dive
7. Scaling
8. Reliability
9. Security
10. Tradeoffs
11. Bottlenecks & Improvements

1. Understand the Requirements

Before designing anything, first understand:

• What are we building?

• What features are needed?

• What scale are we talking about?

• Is consistency important or availability?

Example:

• millions of users?

• low latency?

• real-time updates?

This helps shape the entire design.

2. Estimate the Scale

Do rough calculations:

• requests per second,

• storage,

• traffic,

• daily active users.

The goal is not perfect math.
The goal is to justify your architecture decisions.

3. Start with High-Level Design

Begin with a simple flow:

Client
→ Load Balancer
→ API Gateway
→ Application Servers
→ Cache / Queue / Database

For every component, explain:

• why it exists,

• what problem it solves,

• and why it helps at scale.

4. Design the Database

Decide:

• SQL or NoSQL?

Then discuss:

• partitioning,

• indexing,

• replication,

• sharding.

A big focus should be:

“How will this database scale?”

5. Explain APIs and Data Flow

Show how a request moves through the system.

Example:

Client → Server → Database → Kafka → Notification Service

This shows that you understand real backend workflows.

6. Deep Dive Into Important Parts

This is usually the most important section.

Pick 1–2 complex areas and go deeper.

Examples:

• message ordering in chat apps,

• driver matching in ride-sharing,

• feed generation,

• caching strategy,

• real-time communication.

This is where interviews are often won.

7. Explain How the System Scales

Talk about:

• horizontal scaling,

• caching,

• sharding,

• queues,

• read replicas,

• CDN.

The interviewer wants to know:

“Will this still work if traffic becomes 100x bigger?”

8. Reliability Matters

Strong candidates always discuss failure handling.

Mention:

• retries,

• dead letter queues,

• failover,

• replication,

• idempotency,

• circuit breakers.

Real systems fail all the time.
Good engineers design for failures.

9. Mention Security

Briefly cover:

• HTTPS,

• authentication,

• JWT/OAuth,

• encryption,

• rate limiting.

A small security discussion makes your answer feel complete.

10. Discuss Tradeoffs

This is one of the most important parts.

There is no perfect system.
Every design choice has tradeoffs.

Examples:

• consistency vs availability,

• SQL vs NoSQL,

• synchronous vs asynchronous processing.

The interviewer cares more about:

why you chose something

than the technology itself.

11. End with Bottlenecks and Improvements

Finally, discuss:

• possible bottlenecks,

• scaling challenges,

• hot partitions,

• cache issues,

• database pressure.

Then suggest improvements.

This shows mature engineering thinking.

What Interviewers Actually Want

They are not checking whether you can build Google or Netflix from scratch.

They mainly want to see:

• structured thinking,

• clear communication,

• tradeoff awareness,

• scalability understanding,

• and problem-solving ability.

If your thinking process is clear and structured, even an imperfect design can still be a very strong interview answer.

The defining feature is decoupling:

• Publishers don’t know who is receiving the messages.

• Subscribers don’t need to know who sent the message.

• The Message Broker sits in the middle, handling the routing and delivery.

Core Concepts & Filtering

In Pub/Sub, subscribers usually only want a specific subset of messages. This is handled through filtering:

• Topic-Based Filtering: Messages are published to named channels (e.g., orders, logs). Subscribers receive everything on that channel.

• Content-Based Filtering: The broker examines the message content and only delivers it if it matches specific criteria defined by the subscriber (e.g., “only messages where price > 100“).

In-Depth Examples & Use Cases

1. Event Notification (Decoupling Services)

In a traditional system, if a user makes a purchase, the OrderService might have to manually call the EmailService, ShippingService, and InventoryService. If one is down, the whole process might fail.

• Pub/Sub Approach: The OrderService simply publishes an “Order Created” message to a topic.

• Benefit: The OrderService can “fire and forget”. It doesn’t care if the EmailService is currently offline; the broker will ensure the message is delivered when the service is back online.

• Real-World Example: Split.io uses this to send feature flag updates to millions of apps. If an app is offline, it gets the update as soon as it reconnects.

2. Distributed Caching (State Synchronization)

When you have multiple server instances, you need them to have the same data in their local memory (cache).

• Pub/Sub Approach: When data changes in the database, a message is published to a “Cache Update” topic. All server instances subscribe to this and update their local cache immediately.

• Real-World Example: Seats.io uses this for live seat bookings. When someone buys a ticket, the floor plan is updated across all global caches instantly so two people don’t buy the same seat.

3. Distributed Logging

Managing logs in a distributed system with 100+ servers is difficult if you have to log into each one.

• Pub/Sub Approach: Every server publishes its logs to a central “Logs” topic.

• Parallel Processing: One subscriber can send those logs to Elasticsearch for searching, while another subscriber monitors them for errors to trigger an SMS alert.

4. Handling “Thundering Herds” (Burstability)

In education or live events, thousands of users might join at the exact same second.

• Pub/Sub Approach: A dedicated broker (like Redis or Kafka) is designed to handle massive “fanout” bursts—sending one message to 100,000 people simultaneously.

• Real-World Example: Wooclap uses this so students in a large lecture hall can all see a professor’s question on their phones at the exact same time, even on spotty Wi-Fi.

In modern microservices, “Fire and Forget” is the gold standard. We want Service A to talk to Service B without waiting for a response — ensuring that if one system fails, the whole application doesn’t go down with it.

But when you open the AWS or Azure console, you’re faced with a choice: Message Queue (MQ) or Pub-Sub? Getting this wrong can lead to data loss or a system that’s impossible to scale.

What is a message queue?

A message queue basically contains a publisher, and in between there will be a queue containing messages, and there will be multiple consumers subscribing to that queue. Examples: AWS SQS, RabbitMQ

Let's look at the diagram.

We can see Publisher is going to publish that m n+1 message to the queue, and there are consuming servers A and B.

Let's see how this system behaves over time.

As you can see, the m1 message has been consumed by Consumer A and its no more available in the queue.

When to use a message queue in the system?
When a system use case is like we want to delegate some work to the service, then MQ (Message Queue) would be preferred. When we want a single execution of the message or task. This type of system is known as the point-to-point messaging model.

What is the Pub/Sub messaging model?

The only difference from a message queue is that here we want to deliver our task/message published by the publisher to reach at least once to each of the consumers. Examples: AWS SNS, Apache Kafka

Let's see the flow of data over time.

On the left we have a publisher. Publishing a message to the topic. This topic will have multiple subscribers. This topic will broadcast this message to its subscriber. It will make sure each subscriber will get a copy of that message published into the topic.

Which one to use and when?

Another benefit of using either pub-sub or message queues is that the communication is more durable than traditional synchronous modes of communication. For example, if app A communicates to app B via an asynchronous HTTP call, then if either of the applications goes down, the data is lost and the request must be retried.

Using message queues, if a consumer application instance goes down, then another consumer will be able to handle the message instead. Using pub-sub, if a subscriber is down, then once it has recovered, the messages it has missed will be available for consumption in its subscribing queue.

Finally, context is key. Choosing whether to use pub-sub or message queue architecture comes down to defining exactly how you want the consuming service to behave. The most important factor to keep in mind is asking,

"Does it matter if every consumer gets every message?”
If yes: Use Pub-Sub.
If No: Use a Message Queue.

I have been working with WebSockets for quite some time now, and let me tell you a secret: implementing basic WebSockets isn’t that hard.

But orchestrating a secure, bidirectional communication framework — especially when scaling an enterprise tracking system to handle around 40,000 distributed agents — is an entirely different beast. Scaling them, handling sudden disconnections, and managing state across multiple instances? That is where the real engineering happens.

WebSocket servers are inherently resource-hungry. Before we dive into the architecture of scaling, let’s get on the same page with the vocabulary.

10 WebSocket Terms You Need to Know

If you are building real-time systems, these concepts should be second nature:

• Heartbeat: Pings sent back and forth to verify the connection is still alive.

• Buffer / Undelivered Messages: Storing messages temporarily when a client briefly drops offline.

• Message Routing: Directing the right payload to the right active connection.

• Broadcast: Sending a single message to all connected clients simultaneously.

• Handling Backpressure: Managing the flow of data when the server is sending messages faster than the client can process them.

• Automatic Reconnection: The client’s ability to seamlessly re-establish a dropped connection.

• Message Acknowledgements (ACKs): Confirming that a message was actually received by the client.

• Encryption: Securing the data payload (WSS / TLS).

• Multiplexing: Sending multiple streams of data over a single underlying TCP connection.

• Fallback: Using techniques like HTTP Long Polling if a client’s browser or corporate firewall blocks WebSockets.

The Reality of Scaling WebSockets

When your traffic grows, you have two choices.

1. Vertical Scaling (The Brute Force Approach) This means throwing more CPU and RAM at a single server. Depending on your server resources, you can support a massive amount of connections on one machine.

• The Catch: Single point of failure. If you need to deploy an update, or if the server crashes, every single user gets disconnected at once. That’s a terrible user experience.

2. Horizontal Scaling (The Engineering Approach) This means spinning up multiple server instances.

• The Problem: If User A is connected to Server 1, and User B is connected to Server 2, they cannot talk to each other. Server 1 has no idea User B exists.

The Solution: Redis Pub/Sub

Challenges in Horizontal Scaling

While Redis solves the routing problem, horizontal scaling introduces new headaches:

• Data Synchronization

• Connection State Synchronization

• Making Redis Redundant

• Load Shedding

• Restoring Connections

Handling the “Thundering Herd” (Reconnection Logic)

Connections drop all the time. It’s normal. It happens due to network switching (Wi-Fi to Cellular), proxy timeouts (ALB/API Gateways), or just laptops going to sleep and suspending the TCP connection.

I wrote a specific reconnection logic for my agents to handle unexpected drops. If a server goes down, every single client will instantly try to reconnect at the exact same millisecond. This is called the Thundering Herd problem, and it will instantly crash your server again.

To protect the server, you need Exponential Backoff with Jitter. Jitter adds randomness, spreading the retry wave out over time. Here is the exact logic I use:

function createBackoff({ base = 500, max = 30000, jitter = true } = {}) {
  let attempt = 0;
return {
    next() {
      // Calculate the exponential delay, capped at the max value
      const exponential = Math.min(base * Math.pow(2, attempt), max);
      
      // Apply jitter (randomness) to prevent synchronized retries
      const delay = jitter
        ? exponential * (0.5 + Math.random() * 0.5)
        : exponential;
        
      attempt++;
      return Math.floor(delay);
    },
    reset() {
      attempt = 0;
    },
  };
}

A Final Note: What I Learned Going to Prod

There is a massive misconception in the community about WebSocket capacity. People always focus on how many connections a single instance can hold.

When I took my architecture to production, here was the biggest takeaway:

“A 10k connection load writing 100 messages per second is a far heavier beast than 50k idle connections.”

Throughput and message frequency will choke your CPU and memory long before raw connection counts will. Plan your architecture around your message velocity, not just your concurrent users.

References & Further Reading:

• The WebSocket Protocol Guide (WebSocket.org)

• Scaling Pub/Sub with WebSockets and Redis (Ably)

• When and How to Load Balance WebSockets at Scale (Ably)

This was my interview experience for an AWS Developer role at Brillio. Overall, it was a great learning experience — I got a clear understanding of the expectations companies have from AWS Developers and the kind of skills they look for. 🚀

Some of the topics discussed:

• What is AWS Lambda and how does serverless scaling work?
• Amazon SQS internals — visibility timeout, retries, and DLQ
• SQS vs Kinesis — queueing vs real-time streaming
• Why exceptions are raised in Lambda when consuming SQS messages
• Public Subnet vs Private Subnet
• Internet Gateway vs NAT Gateway
• Components of VPC
• NACL vs Security Groups
• What are Pre-Signed URLs in S3?
• Different S3 Storage Classes and real-world use cases
• How to solve HTTP 413 (Entity Too Large) errors in AWS architectures
• Node.js AWS SDK code to retrieve images from an S3 bucket

We also discussed a production-level architecture:

Agent Upload → S3 Bucket → Metadata stored in OpenSearch → Backend fetches S3 Key → Generates Pre-Signed URL → Frontend displays secure images

Key Learning 💡

S3 is optimized for object storage, not metadata searching. That’s why storing searchable metadata in OpenSearch while keeping images private in S3 is a scalable and secure approach.

One thing I realized during these discussions is that hands-on experience with deployments and cloud architecture makes a huge difference. It helps in understanding how systems handle scale, retries, failures, security, and traffic patterns in real-world production environments.

Tech Stack Discussed:
AWS Lambda | SQS | S3 | OpenSearch | VPC | Node.js | Serverless Architecture

These discussions were a great reminder that strong backend engineering is not just about coding, but also about designing scalable, secure, and fault-tolerant systems.

Thank you — see you at deployment 🚀

#AWS #Serverless #Lambda #SQS #S3 #OpenSearch #NodeJS #BackendDevelopment #SoftwareEngineering #CloudComputing #SystemDesign #Microservices #AWSDeveloper #DistributedSystems

🔵 Pattern 1: “Pick / Not Pick” (FULL TREE)

✅ Code (Combination Sum style — allows full tree)

class Solution {
    List<List<Integer>> ans = new ArrayList<>();
void ok(int index, int[] nums, int target, List<Integer> temp) {
        if (target == 0) {
            ans.add(new ArrayList<>(temp));
            return;
        }
        if (index == nums.length) return;
        // ✅ TAKE
        if (nums[index] <= target) {
            temp.add(nums[index]);
            ok(index, nums, target - nums[index], temp); // reuse allowed
            temp.remove(temp.size() - 1);
        }
        // ❌ NOT TAKE
        ok(index + 1, nums, target, temp);
    }
}

👉 Used when:

• You don’t care about duplicates

• OR problem is simple include/exclude

• OR reuse of elements is allowed (like in Combination Sum)

🌳 Tree Shape

At every index → 2 choices

        index
        /     \
     take     skip

👉 Size ≈ 2^n (full binary tree)
👉 Explores all subsets / possibilities
👉 Can generate duplicates → ❌ inefficient for duplicate inputs

🔴 Pattern 2: “For Loop + Pruning” (REDUCED TREE)

👉 Used when:

• You want to avoid duplicates

• You want controlled branching

• Input contains duplicates

• Each element can be used only once (like in Combination Sum II)

✅ Code (Combination Sum 2 style — optimized)

class Solution {
    List<List<Integer>> ans = new ArrayList<>();
void ok(int index, int[] nums, int target, List<Integer> temp) {
if (target == 0) {
            ans.add(new ArrayList<>(temp));
            return;
        }
        for (int i = index; i < nums.length; i++) {
            // 🚨 skip duplicates
            if (i > index && nums[i] == nums[i - 1]) continue;
            if (nums[i] > target) break;
            temp.add(nums[i]);
            ok(i + 1, nums, target - nums[i], temp); // move forward
            temp.remove(temp.size() - 1);
        }
    }
}

🌳 Tree Shape

At each level → choose ONE among many

        level
     /    |    \
   pick  pick  pick

👉 Size much smaller than 2^n
👉 No duplicate branches ✅
👉 More optimized for interview constraints

🔥 Look at Combination Sum vs Combination Sum II

Take a simpler case:

nums = [1, 1, 2]
target = 3

Sorted:

[1a, 1b, 2]   (same value, different indices)

❌ Your Approach (Pick / Not Pick)

At every index → 2 choices

🌳 Recursion Tree (your code)

                        []
               /                      \
          take 1a                  skip 1a
           [1]                       []
        /       \               /          \
   take 1b    skip 1b     take 1b       skip 1b
    [1,1]        [1]        [1]            []
    /   \       /   \      /   \          /   \
 take2 skip2  take2 skip2 take2 skip2  take2 skip2
 [1,1,2] ...  [1,2] ...   [1,2] ...    [2] ...

🎯 Look at duplicates

You get:

[1,2]  ← from (take 1a, skip 1b, take 2)
[1,2]  ← from (skip 1a, take 1b, take 2)

👉 Same combination, different paths

💥 What’s happening?

• Tree size ≈ 2^n

• Duplicate values → duplicate branches

• You generate:

[1,2] multiple times

Then:

HashSet removes duplicates ❌ (too late, too costly)

✅ Optimized Approach (For-loop + Skip duplicates)

🔑 Key line:

if (i > index && nums[i] == nums[i - 1]) continue;

🌳 Recursion Tree (optimized)

                []
          /           \
       pick 1a        pick 2
        [1]           [2]
      /      \
  pick 1b    pick 2
   [1,1]      [1,2]

🚨 Notice:

• We DO NOT start a branch with 1b at same level

• So this path is removed:

(skip 1a → pick 1b) ❌

👉 This is the exact pruning step that reduces tree size

🧠 Final Insight (Interview Gold)

Pick/Not Pick builds a full binary tree (2^n), while the for-loop pattern prunes duplicate branches at the same level, reducing unnecessary recursion and improving performance.

“See you at the deployment’’
Thank you !

✅ Code (Combination Sum style – allows full tree)

class Solution {
    List<List<Integer>> ans = new ArrayList<>();

    void ok(int index, int[] nums, int target, List<Integer> temp) {

        if (target == 0) {
            ans.add(new ArrayList<>(temp));
            return;
        }

        if (index == nums.length) return;

        // ✅ TAKE
        if (nums[index] <= target) {
            temp.add(nums[index]);
            ok(index, nums, target - nums[index], temp); // reuse allowed
            temp.remove(temp.size() - 1);
        }

        // ❌ NOT TAKE
        ok(index + 1, nums, target, temp);
    }
}

👉 Used when:

• You don’t care about duplicates
  

• OR problem is simple include/exclude
  

• OR reuse of elements is allowed (like in Combination Sum)
  

🌳 Tree Shape

At every index → 2 choices

         index
        /     \
     take     skip

👉 Size ≈ 2^n (full binary tree)

👉 Explores all subsets / possibilities

👉 Can generate duplicates → ❌ inefficient for duplicate inputs

🔴 Pattern 2: “For Loop + Pruning” (REDUCED TREE)

👉 Used when:

• You want to avoid duplicates
  

• You want controlled branching
  

• Input contains duplicates
  

• Each element can be used only once (like in Combination Sum II)
  

✅ Code (Combination Sum 2 style – optimized)

class Solution {
    List<List<Integer>> ans = new ArrayList<>();

    void ok(int index, int[] nums, int target, List<Integer> temp) {

        if (target == 0) {
            ans.add(new ArrayList<>(temp));
            return;
        }

        for (int i = index; i < nums.length; i++) {

            // 🚨 skip duplicates
            if (i > index && nums[i] == nums[i - 1]) continue;

            if (nums[i] > target) break;

            temp.add(nums[i]);
            ok(i + 1, nums, target - nums[i], temp); // move forward
            temp.remove(temp.size() - 1);
        }
    }
}

🌳 Tree Shape

At each level → choose ONE among many

         level
     /    |    \
   pick  pick  pick

👉 Size much smaller than 2^n

👉 No duplicate branches ✅

👉 More optimized for interview constraints

🔥 Look at Combination Sum vs Combination Sum II

Take a simpler case:

nums = [1, 1, 2]
target = 3

Sorted:

[1a, 1b, 2]   (same value, different indices)

❌ Your Approach (Pick / Not Pick)

At every index → 2 choices

🌳 Recursion Tree (your code)

                         []
               /                      \
          take 1a                  skip 1a
           [1]                       []
        /       \               /          \
   take 1b    skip 1b     take 1b       skip 1b
    [1,1]        [1]        [1]            []
    /   \       /   \      /   \          /   \
 take2 skip2  take2 skip2 take2 skip2  take2 skip2
 [1,1,2] ...  [1,2] ...   [1,2] ...    [2] ...

🎯 Look at duplicates

You get:

[1,2]  ← from (take 1a, skip 1b, take 2)
[1,2]  ← from (skip 1a, take 1b, take 2)

👉 Same combination, different paths

💥 What’s happening?

• Tree size ≈ 2^n
  

• Duplicate values → duplicate branches
  

• You generate:
  

[1,2] multiple times

Then:

HashSet removes duplicates ❌ (too late, too costly)

✅ Optimized Approach (For-loop + Skip duplicates)

🔑 Key line:

if (i > index && nums[i] == nums[i - 1]) continue;

🌳 Recursion Tree (optimized)

                    []
          /           \
       pick 1a        pick 2
        [1]           [2]
      /      \
  pick 1b    pick 2
   [1,1]      [1,2]

🚨 Notice:

• We DO NOT start a branch with 1b at same level
  

• So this path is removed:
  

(skip 1a → pick 1b) ❌

👉 This is the exact pruning step that reduces tree size

🧠 Final Insight (Interview Gold)

Pick/Not Pick builds a full binary tree (2^n), while the for-loop pattern prunes duplicate branches at the same level, reducing unnecessary recursion and improving performance.

The matrix must be modified in-place.

Follow up: Could you solve it using O(1) space?

Example 1:

Input: matrix = [
  [1,2,3],
  [4,0,5],
  [6,7,8]
]

Output: [
  [1,0,3],
  [0,0,0],
  [6,0,8]
]

Solution Brute Force

Create another matrix.

Whenever a 0 is found, make its entire row and column 0 in the new matrix.

Complexity

• TC → O(m*n*(m+n))

• SC → O(m*n)

Better Approach

Use two arrays:

• row[]

• col[]

If matrix[i][j] == 0, mark:

row[i] = 1;
col[j] = 1;

Then traverse again and make all marked rows and columns zero.

Complexity

• TC → O(m*n)

• SC → O(m+n)

Optimal Approach — O(1) Space

Instead of extra arrays, use:

• first row → column markers

• first column → row markers

Catch

matrix[0][0] is shared by both first row and first column.

class Solution {
    public void setZeroes(int[][] mat) {
        int m = mat.length;
        int n = mat[0].length;

        boolean firstRow = false;
        boolean firstCol = false;

        // check first row
        for (int j = 0; j < n; j++) {
            if (mat[0][j] == 0) {
                firstRow = true;
                break;
            }
        }

        // check first column
        for (int i = 0; i < m; i++) {
            if (mat[i][0] == 0) {
                firstCol = true;
                break;
            }
        }

        // mark rows and columns
        for (int i = 1; i < m; i++) {
            for (int j = 1; j < n; j++) {
                if (mat[i][j] == 0) {
                    mat[i][0] = 0;
                    mat[0][j] = 0;
                }
            }
        }

        // set zeroes
        for (int i = 1; i < m; i++) {
            for (int j = 1; j < n; j++) {
                if (mat[i][0] == 0 || mat[0][j] == 0) {
                    mat[i][j] = 0;
                }
            }
        }

        // first row
        if (firstRow) {
            for (int j = 0; j < n; j++) {
                mat[0][j] = 0;
            }
        }

        // first column
        if (firstCol) {
            for (int i = 0; i < m; i++) {
                mat[i][0] = 0;
            }
        }
    }
}

Complexity

• TC → O(m*n)

• SC → O(1)

‘See you at deployment’
Thank you !

Topics To be Discussed…

1. Fan-Out Pattern
2. Fan-In Pattern
3. Real World System using these pattern
4. Celebrity problem / Hot keys in Fan-Out pattern
5. Straggler problem in Fan-In pattern
6. Interview Question on these pattern
7. Related Topics and Examples.

1. Fan-out Architecture: The “Distributor”

Fan-out occurs when a single input or event triggers multiple parallel processes or is delivered to multiple destinations simultaneously.

How it Works

1. Event Producer: A single service generates a message or a task.

2. Message Broker: The message is sent to a topic (e.g., in Kafka or SNS).

3. Multiple Consumers: Several independent services subscribe to that topic. Each service gets a copy of the message and performs its own specific logic.

Deep-Dive Example: Social Media Post (e.g., Twitter/X)

When a celebrity with 10 million followers posts a “tweet,” the system uses a fan-out pattern:

• The Event: User clicks “Post.”

• The Fan-out: The system pushes that tweet into the “Timeline Cache” of all 10 million followers.

• Benefit: When followers open their app, the data is already there (read-heavy optimization).

2. Fan-in Architecture: The “Aggregator”

Fan-in is the mathematical opposite. it is the process of combining results from multiple independent sources or parallel tasks into a single unified result.

How it Works

1. Multiple Inputs: Various workers or upstream services finish their individual tasks.

2. Synchronisation Point: A coordinator or a “Barrier” waits for all (or a quorum) of these tasks to complete.

3. Aggregation: The results are merged, summarized, or reduced into a final output.

Deep-Dive Example: Search Engine Results (e.g., Google)

When you search for “Best Pizza,” the system doesn’t search one giant database.

• Parallel Search: The query is sent to hundreds of “leaf nodes” (shards of the web index).

• The Fan-in: An aggregator service collects the top 10 results from every shard, re-ranks them by relevance, and presents you with the final top 10 list.

Real World System using these pattern

🚕 Case Study: The Uber Notification & Reporting System

💨 The Fan-Out Pattern: Total Decoupling

When a “Ride Completed” event triggers in the Uber app, we can’t afford a single delay. Several critical but independent operations need to happen simultaneously, and one slow process cannot block the rest.

The Fan-Out System Flow:

• ⚡️ The Trigger: A user clicks “Complete Ride,” generating a “Ride Completed” event.

• 📡 The Exchange: The system publishes this event to a message broker/exchange (e.g., Kafka, RabbitMQ).

• 🎉 The Fan-Out: The single message is fanned out and immediately picked up by three separate, concurrent consumers:

1. 💳 Billing Service: Instantly calculates the final fare and initiates the credit card charge.

2. 🔔 Push Notification Service: Pings the user’s phone with a “Rate your driver!” alert.

3. 📈 Analytics Service: Updates the driver’s lifetime stats, completion rates, and adds the location data to heatmaps.

💡 Why Fan-Out? Total independence. If the Billing Service is under high load or down, it does not stop the user from receiving their crucial notification or the Analytics Service from logging data. This isolation maximizes reliability and responsiveness.

🧱 The Fan-In Pattern: Strict Coordination

Fast-forward to Sunday night. The requirements change from “speed” to “completion and correctness.” The goal: generate a driver’s “Weekly Earnings Report.” This cannot happen instantly and requires precise synchronization.

The Fan-In System Flow:

• 🛠️ The Fan-Out (Sub-tasks): The Reporter system triggers 7 parallel jobs — one for each day of the week — to fetch detailed earning data from cold storage.

• 🛑 The Barrier: A coordination service sets a synchronization “barrier,” waiting until all 7 jobs confirm completion.

• 🤝 The Fan-In (The Aggregation): A specialized Reporter Service collects all 7 daily data sets, sums the daily totals, calculates tax deductions, and merges the findings into a single, comprehensive PDF report.

🚨 Critical System Design Detail: Handling Failures In Fan-In, the most critical decision is coordination logic. If the job for Saturday fails or the data is missing, the Fan-In coordinator must be programmed with a policy:

1. Fail-fast: Show the driver an error message.

2. Partial-success: Generate the report but clearly mark Saturday’s data as “Pending/Unavailable.” This is a major discussion point in interviews!

2. Case Study: E-commerce Order Fulfillment

In a complex e-commerce system like Amazon, checking out is a high-stakes Fan-out/Fan-in dance.

The Workflow

1. Fan-out (Inventory Check): When a user views a cart with 10 different items, the system fans out 10 requests to different warehouse databases to check stock levels.

2. Fan-in (Cart Validation): The frontend “Fans-in” these 10 responses. Only if all items are confirmed available does the “Proceed to Checkout” button turn orange.

3. Fan-out (Order Success): Once payment is confirmed:

4. Email Service sends a receipt.

• Warehouse Service prints a packing slip.

• Inventory Service decrements the count.

• Loyalty Service adds points.

Celebrity problem / Hot keys / Thundering Herd

In a Fan-out architecture, engineers typically use a Hybrid Push/Pull Model. This is a classic system design interview deep-dive.

1. The Hybrid Model: Push for “Peons,” Pull for “Kings”

In a standard fan-out, when User A posts, the system “pushes” the post into the timelines of all followers. For a celebrity with 100M followers, this write-operation is catastrophic.

• The Strategy: * Low-Follower Users (Push): When they post, fan-out to all followers’ caches immediately. This keeps latency low for the average user.

• Celebrities/High-Follower Users (Pull): When they post, do not fan-out. Instead, store the post in a single “Celebrity Post Store.”

• The Merge on Read: When a follower opens their feed, the system pulls the pre-computed “Push” feed and then queries the “Celebrity Store” for any new posts from the celebrities they follow. It merges them on the fly.

The Straggler Problem / “Tail Latency” problem

It occurs when a single task in a parallel computing job takes significantly longer to complete than the others. If 99 workers finish in 1 second, but 1 worker (the straggler) takes 30 seconds:The User Experience is 30 seconds of waiting, not 1 second.

Real-World Solutions (Interview Answers)

A. Speculative Execution (Hedged Requests)

This is the strategy used by Google (MapReduce) and Hadoop.

• How it works: The system monitors the progress of all workers. If it sees that 95% of workers are done, but a few are still “straggling,” it launches a duplicate of those specific tasks on different, idle workers.

• The Race: The system accepts the result from whoever finishes first and kills the other one.

• Trade-off: It uses more resources (CPU/Network), but it drastically reduces the “tail latency.”

B. Load Balancing with “Least Loaded”

• How it works: Instead of a simple Round-Robin fan-out, use a load balancer that tracks how many active tasks each worker has.

• Benefit: This prevents sending a new chunk to a worker that is already struggling with a “heavy” task.

C. Graceful Degradation (Partial Results)

• How it works: In non-critical systems (like a Search Engine or a “Recommended Videos” list), if a straggler exceeds a strict timeout (e.g., 500ms), the Fan-in service simply ignores it.

• The Result: The user sees 9 out of 10 search results immediately, which is better than waiting 30 seconds for all 10.

Interview Question

• Q: How do you handle idempotency in a Fan-out system?

• Why it matters: If a fan-out message is delivered twice (at-least-once delivery), you don’t want to charge a customer twice or send two notifications.

• The Answer: Use Idempotency Keys (UUIDs). The receiver checks a cache (like Redis) to see if that specific Task ID has already been processed before executing.

• Q: In a Fan-in architecture, how do you handle “Partial Availability”?

• The Scenario: You fan-out a search to 10 shards. 9 return in 50ms, 1 is timed out. Do you wait or return 90% of the results?

• The Answer: Discuss Graceful Degradation. For a search engine, 90% of the index is better than a 500 error. For a banking transaction, you must wait or fail the whole thing (Atomic operations).

• Q: How do you scale the “Aggregator” in a Fan-in if the data being merged is too big for one machine’s memory?

• The Answer: Use Multi-level Fan-in (Hierarchical Merging). Instead of 1,000 workers sending to 1 aggregator, have 1,000 workers send to 10 “Intermediate Aggregators,” which then send to 1 “Final Aggregator.”

Related Topics and Examples

Exponential Backoff : is a error handling strategy where a request will get retry after some time on the down service .
The delay between each request will be increase exponential .

Jitter Concept : if a server goes down and 10k clients all start their exponential backoff at the exact same time, they will still all hit the server simultaneously at the 1s, 2s, 4s, and 8s marks. This is called Synchronization.

To solve this, we add Jitter (randomness). Instead of waiting exactly 4 seconds, the client waits for a random value between 0 and 4 seconds.

. Interview “Pro-Tips”

• The Ceiling: Always mention a Maximum Backoff Cap. You don’t want a client waiting 24 hours between retries if the math keeps doubling. You might cap the delay at 30 or 60 seconds.

• The “Circuit Breaker” Link: If an interviewer asks about Backoff, mention the Circuit Breaker Pattern. While Backoff helps the client retry, a Circuit Breaker stops the client from even trying if it knows the server is definitely down, saving resources on both ends.

See you at the deployment. 🚀

Recently, I was discussing interview experiences with a junior, and one thing became very clear — SDE interviews are evolving.

It’s no longer just about solving DSA problems in isolation.
The focus is shifting toward real-world engineering scenarios.

The Assessment Structure

The assessment typically includes two sections:

1. DSA Problem

The problem isn’t always based on a single pattern.
It can involve a mix of concepts like Graph + Map, where:

• Identifying the right approach quickly is crucial

• Modeling the problem correctly matters more than brute force

• Time pressure plays a big role

2. Repository-Based Question (Repo Round)

This is where things get interesting.

Instead of coding from scratch, candidates may be given a complete project (Frontend + Backend, often Spring Boot) and asked to fix a broken feature.

For example:

• A Notification Service not working properly in a system

• Emails or alerts not being triggered due to a failed event flow

• Caching issues causing stale or incorrect data to be served

This round tests:

• Navigating an unfamiliar codebase

• Understanding end-to-end flow (controller → service → integration)

• Debugging issues efficiently

• Making precise fixes without breaking existing functionality

Key Takeaways

• Strong DSA is important, but not sufficient

• Reading and debugging existing codebases is a critical skill

• Backend fundamentals (Spring Boot, APIs, system design flow) matter a lot

• Practicing on real repositories is a game changer

What This Means

Interviews are clearly shifting:

• Less focus on writing everything from scratch

• More focus on how effectively you can work within a real system

Final Thought

The real skill is not just solving problems.
It’s understanding systems.

See you at the deployment. 🚀

The Interview Process

Round 1: The Online Assessment (OA)

The OA was a mix of core fundamentals and problem-solving. It wasn’t just about “coding”; it was about how you think through a system.

• Java OOPs: Two questions focused heavily on Object-Oriented programming principles (Inheritance, Polymorphism, etc.).

• Debugging: You are given snippets of broken code and asked to identify the logical or syntax errors. This is crucial for a TSE role.

• DSA: One standard Data Structures and Algorithms question. It wasn’t LeetCode Hard, but you need your basics (Strings/Arrays) to be rock solid.

Rounds 2 & 3: Technical & Scenario-Based

These rounds move away from the IDE and into the “real world” of support engineering.

• Customer Handling: How do you deal with an angry enterprise client? How do you prioritize a “Priority 1” ticket?

• Bug Management: Scenario questions on identifying if a problem is a configuration issue, a platform bug, or a custom code error.

• The “Disengagement” Strategy: How do you handle a situation where a customer is asking for something out of scope or refusing to follow technical advice?

• Salesforce Ecosystem: Questions about specific Salesforce products. You don’t need to be a certified admin, but knowing the cloud landscape (Sales, Service, Marketing Cloud) is a huge plus.

The Perks: The “Salesforce Life”

Let’s be real — the benefits at Salesforce are top-tier. If you get the offer, you can look forward to:

• The Gear: A top-of-the-line MacBook and a high-end monitor for your home/office setup.

• The Office Experience: In-house Baristas making custom coffee, excellent food, and reliable cab services for commuters.

• Well-being: They truly invest in making the workspace feel like a community.

The Cons:

• The Nature of the Work: It is a support role. You spend more time troubleshooting and communicating than building.

• Technical Growth: For someone who lives and breathes code, you might find it lacking. There isn’t much “heavy lifting” in terms of development.

• WLB & Pay: While the pay is good, it doesn’t match the AMTS (Associate Member of Technical Staff) or MTS tracks. The Work-Life Balance in support can also be unpredictable due to shifts and urgent tickets.

Final Verdict

If you are a hardcore technical person — a backend specialist, a frontend wizard, or a system design enthusiast — I would suggest aiming for the AMTS or MTS roles instead. The pay is significantly higher, the WLB is generally better, and you’ll actually be building the systems rather than just fixing them.

Thank you !
“See you at the Deployment.”- Hrithik

Round 1: Technical Screening

1. Data Structures & Algorithms

I was asked to solve two standard DSA problems:

• Find Minimum in Rotated Sorted Array

• Longest Substring Without Repeating Characters

The focus was on optimal approaches, time complexity, and edge cases.

2. SQL Questions

• I was given 3 tables and asked to:

• Perform joins and aggregations

• Retrieve combined data from all tables

• The interviewer emphasized query optimization and correctness

3. System Design & Concepts

Basic conceptual questions were asked on:

• CDN (Content Delivery Network)

• Load Balancer

• API Gateway

• DynamoDB

4. DynamoDB Deep Dive

• How data is stored in Amazon DynamoDB

• Understanding of:

• Partition keys

• Sorting mechanism

• Scalability and distributed storage

5. Python Fundamentals

• Differences between List vs Tuple

• Basic Python concepts and use cases

Overall Experience

The round focused on a balanced evaluation of:

• Problem-solving skills (DSA)

• Database knowledge (SQL)

• System design fundamentals

• Python core concepts

DynamoDB provides two types of secondary indexes:

• Local Secondary Index (LSI)

• Global Secondary Index (GSI)

Both serve to extend your query capabilities, but they differ significantly in terms of flexibility, performance, and use cases.

🔹 What is an LSI (Local Secondary Index)?

An LSI allows you to create an alternative sort key for queries while keeping the same partition key as the base table.

For example:

• Base Table: CustomerId (PK) + OrderId (SK)

• LSI: CustomerId (PK) + OrderDate (SK)

This means you can still query all orders for a customer, but now sort or filter them by date (or another attribute).

Great question 👍 This is where many people get confused. Let’s clear it up:

🔹 How LSI Works

When you create a table in DynamoDB, you define:

• Partition Key (PK) → required

• Sort Key (SK) → optional

Now, with an LSI (Local Secondary Index):

• The Partition Key stays the same as the base table.

• You can define a different Sort Key (up to 5 LSIs per table).

So yes — effectively, an item can be queried using multiple sort keys depending on which LSI you use.

📌 Example

Base Table

• Partition Key (PK): CustomerId

• Sort Key (SK): OrderId

This means you can query by CustomerId and order results by OrderId.

Add LSI #1

• Partition Key (PK): CustomerId

• Sort Key (SK): OrderDate

Now you can query all orders for a customer but sort/filter by OrderDate.

Add LSI #2

• Partition Key (PK): CustomerId

• Sort Key (SK): Price

Now you can query all orders for a customer but sort/filter by Price.

🔑 Important Notes

• You don’t literally add a “second sort key” to the base table schema.
  Instead, DynamoDB maintains separate index structures for each LSI.

• Each LSI still points back to the same base item but organizes them differently for querying.

• You can create up to 5 LSIs per table.

👉 Think of it this way:
The base table has only one sort key, but LSIs give you alternate “views” of the data, each sorted by a different attribute.

🔹 What is a GSI (Global Secondary Index)?

A GSI lets you create a completely new partition key (and optionally a sort key). It’s not restricted to the base table’s partition key.

For example:

• Base Table: CustomerId (PK) + OrderId (SK)

• GSI: ProductId (PK) + OrderDate (SK)

Now, instead of looking up by customer, you can query by product

✅ Advantages and Disadvantages

Local Secondary Index (LSI)

Advantages:

• Can return strongly consistent reads.

• Useful for queries where partition key remains the same but you need a new sort order.

• No extra cost for throughput (shares base table’s RCU/WCU).

Disadvantages:

• Must be defined at table creation time (not flexible).

• Limited to 10GB per partition.

• Dependent on base table’s throughput (no independent scaling).

Global Secondary Index (GSI)

Advantages:

• Can be added anytime after table creation.

• Allows completely new partition and sort keys.

• Scales independently of the base table with its own capacity units.

Disadvantages:

• Only supports eventually consistent reads.

• Involves additional cost (separate RCU/WCU).

• More complex maintenance compared to LSI.

🔑 When to Use LSI vs GSI

• Use LSI when:

• You need different sorting or filtering on the same partition key.

• Strongly consistent reads are important.

• Use GSI when:

• You need completely new access patterns.

• Your queries are based on attributes other than the base partition key.

• You want indexes that scale independently of the base table.

📝 Conclusion

Both LSI and GSI are powerful features in DynamoDB, but their use cases are different.

• Choose LSI if you want additional sort keys with the same partition key and need strong consistency.

• Choose GSI if you need new partition keys, more flexibility, or want to add indexes after the table is created.

Designing your indexes upfront with the right strategy ensures your DynamoDB table is efficient, cost-effective, and scalable for future access patterns.