Question 1

Compare NoSQL and SQL databases in the context of a Swiggy-like application. What factors would influence your choice between the two?

Accepted Answer

When building a Swiggy-like application, the choice between NoSQL and SQL databases is crucial, as it impacts data modeling, scalability, and performance.

SQL Databases:  
- Structure: SQL databases are relational and use structured query language (SQL) for defining and manipulating data. They store data in tables with predefined schemas.  
- ACID Compliance: They provide strong consistency and support ACID (Atomicity, Consistency, Isolation, Durability) properties.  
- Use Cases: Ideal for applications requiring complex queries and transactions, such as managing user accounts and orders.

NoSQL Databases:  
- Structure: NoSQL databases are non-relational and can store unstructured or semi-structured data. They come in various types like document stores, key-value pairs, column-family stores, and graph databases.  
- Scalability: They are designed for horizontal scalability, making them suitable for handling large volumes of data and high-velocity applications.  
- Use Cases: Suitable for applications with high write loads and variable data structures, such as user-generated content and product catalogs.

Factors Influencing the Choice:  
1. Data Structure: If the application requires complex relationships and transactions, a SQL database like PostgreSQL could be more suitable. For semi-structured data (like user reviews), a NoSQL database like MongoDB might be more appropriate.  
2. Scalability Needs: For applications expecting rapid growth, a NoSQL database can provide better scalability.  
3. Development Speed: NoSQL databases often allow for faster iterations and schema changes, which can be an advantage in agile development environments.  
4. Consistency Requirements: If strong consistency is paramount (e.g., managing transaction records), SQL databases are favored.

Example of SQL Table Creation:  
```sql  
CREATE TABLE Users (  
    UserID INT PRIMARY KEY,  
    Username VARCHAR(100),  
    PasswordHash VARCHAR(255),  
    Email VARCHAR(100)  
);  
```  
Example of NoSQL Document in MongoDB:  
```json  
{  
    "UserID": 1,  
    "Username": "john_doe",  
    "Orders": [  
        {  
            "OrderID": 101,  
            "Status": "Delivered"  
        },  
        {  
            "OrderID": 102,  
            "Status": "Pending"  
        }  
    ]  
}  
```  
In summary, the choice between NoSQL and SQL databases should be based on the specific requirements of the application, including data structure, scalability, and the need for consistency.

Question 2

Can you explain the four pillars of Object-Oriented Programming (OOP) and provide examples of each using Python?

Accepted Answer

The four pillars of Object-Oriented Programming (OOP) are Encapsulation, Abstraction, Inheritance, and Polymorphism. Below are detailed explanations and code examples for each pillar:

1. Encapsulation: This is the bundling of data (attributes) and methods (functions) that operate on the data into a single unit or class. Encapsulation restricts direct access to some of the object's components.
   ```python
   class BankAccount:
       def __init__(self, owner, balance=0):
           self.owner = owner
           self.__balance = balance  # Private attribute

def deposit(self, amount):
           if amount > 0:
               self.__balance += amount

def get_balance(self):
           return self.__balance

account = BankAccount('John Doe')
   account.deposit(100)
   print(account.get_balance())  # Output: 100
   ```

2. Abstraction: Abstraction is the concept of hiding the complex implementation details and showing only the essential features of the object.
   ```python
   from abc import ABC, abstractmethod

class Shape(ABC):
       @abstractmethod
       def area(self):
           pass

class Circle(Shape):
       def __init__(self, radius):
           self.radius = radius
       
       def area(self):
           return 3.14 * self.radius  2

circle = Circle(5)
   print(circle.area())  # Output: 78.5
   ```

3. Inheritance: Inheritance allows a class to inherit properties and methods from another class. This promotes code reusability.
   ```python
   class Vehicle:
       def start(self):
           return 'Vehicle started'

class Car(Vehicle):
       def honk(self):
           return 'Honk!'

my_car = Car()
   print(my_car.start())  # Output: Vehicle started
   print(my_car.honk())   # Output: Honk!
   ```

4. Polymorphism: Polymorphism allows methods to do different things based on the object it is acting upon, even if they share the same name.
   ```python
   class Dog:
       def sound(self):
           return 'Bark'

class Cat:
       def sound(self):
           return 'Meow'

def animal_sound(animal):
       print(animal.sound())

dog = Dog()
   cat = Cat()
   animal_sound(dog)  # Output: Bark
   animal_sound(cat)  # Output: Meow
   ```

These examples illustrate the core principles of OOP, showcasing how they can be applied in Python.

Question 3

How do you create a simple REST API using Node.js? Provide an example.

Accepted Answer

Creating a REST API with Node.js involves setting up an HTTP server that can respond to requests. Express.js is a popular framework to simplify this process. Below is a simple example of a REST API that manages a list of users.

Example: 
```javascript
const express = require('express');
const app = express();
const PORT = 3000;

app.use(express.json()); // Middleware to parse JSON requests

let users = [];

// GET all users
app.get('/users', (req, res) => {
    res.json(users);
});

// POST a new user
app.post('/users', (req, res) => {
    const newUser = req.body;
    users.push(newUser);
    res.status(201).json(newUser);
});

// GET a user by ID
app.get('/users/:id', (req, res) => {
    const user = users.find(u => u.id === parseInt(req.params.id));
    if (!user) return res.status(404).send('User not found');
    res.json(user);
});

// Start the server
app.listen(PORT, () => {
    console.log(`Server is running on http://localhost:${PORT}`);
});
```

In this example, we set up a simple REST API with three endpoints: one to get all users, one to add a new user, and one to get a user by their ID. The server listens on port 3000, and it uses Express middleware to parse incoming JSON requests.

Question 4

Can you explain the data structures of stacks and queues? Provide code examples for both.

Accepted Answer

Stacks and queues are fundamental data structures in computer science. A stack follows the Last In First Out (LIFO) principle, while a queue follows the First In First Out (FIFO) principle.

Stack Example: 
```javascript
class Stack {
    constructor() {
        this.items = [];
    }

push(element) {
        this.items.push(element);
    }

pop() {
        if (this.isEmpty()) return null;
        return this.items.pop();
    }

peek() {
        return this.items[this.items.length - 1];
    }

isEmpty() {
        return this.items.length === 0;
    }
}

const stack = new Stack();
stack.push(1);
stack.push(2);
console.log(stack.pop()); // Output: 2
console.log(stack.peek()); // Output: 1
```

Queue Example: 
```javascript
class Queue {
    constructor() {
        this.items = [];
    }

enqueue(element) {
        this.items.push(element);
    }

dequeue() {
        if (this.isEmpty()) return null;
        return this.items.shift();
    }

front() {
        return this.items[0];
    }

isEmpty() {
        return this.items.length === 0;
    }
}

const queue = new Queue();
queue.enqueue(1);
queue.enqueue(2);
console.log(queue.dequeue()); // Output: 1
console.log(queue.front()); // Output: 2
```

In these examples, we define a simple `Stack` class with methods to push, pop, and peek at the top element, as well as a `Queue` class with methods for enqueueing, dequeueing, and checking the front element. Both data structures handle edge cases like empty states gracefully.

Question 5

How would you design a microservices architecture for a food delivery platform like Swiggy, focusing on scalability and fault tolerance?

Accepted Answer

Designing a microservices architecture for a food delivery platform like Swiggy involves breaking down the application into smaller, independently deployable services that can scale independently and provide fault tolerance. Key components include:

1. Service Decomposition: Identify core services such as User Service, Restaurant Service, Order Service, Delivery Service, and Notification Service. Each service should focus on a single responsibility.

2. API Gateway: Implement an API Gateway to handle requests and route them to the appropriate microservice. This also helps in implementing cross-cutting concerns like authentication, logging, and rate limiting.

3. Service Communication: Use asynchronous messaging (like RabbitMQ or Kafka) for communication between services, which helps in decoupling and enhances fault tolerance.

4. Database per Service: Each microservice should have its own database to avoid coupling and ensure that each service can scale independently.

5. Load Balancing and Auto-scaling: Use a load balancer to distribute incoming traffic evenly across instances of a service. Implement auto-scaling policies based on CPU usage or request counts to handle varying loads.

Here’s a high-level design diagram for the architecture:
```
+-------------------+          +-------------------+
|    API Gateway    | <-----> |  Service Discovery |
+-------------------+          +-------------------+
          |                              |
          |                              |
+------------------+        +------------------+
|   User Service    |        | Restaurant Service |
+------------------+        +------------------+
          |                              |
          |                              |
+------------------+        +------------------+
|   Order Service   |        |  Delivery Service  |
+------------------+        +------------------+
          |                              |
          |                              |
+------------------+        +------------------+
| Notification Service|      |  Analytics Service  |
+------------------+        +------------------+
```
This architecture ensures that the system is modular, scalable, and resilient to failure. Each service can be developed, deployed, and scaled independently, ensuring high availability and performance under load.

Overall, this design is crucial for a complex system like Swiggy, where multiple services need to work together seamlessly.

SarthiQ

Interview Preparation Guide

Swiggy
Questions & Answers

Document Details

Need Help?

Top Swiggy Interview Questions

Swiggy Interview Questions

A Software Engineer was asked

A Software Engineer was asked

Backend Developer

Software Engineer

Interview Preparation Guide

SwiggyQuestions & Answers

Document Details

Need Help?

Top Swiggy Interview Questions

Swiggy Interview Questions

A Software Engineer was asked

A Software Engineer was asked

Backend Developer

Software Engineer

Swiggy
Questions & Answers