+### 1.1. Monolithic vs Microservices
-Monolithic Architecture:
-- Imagine all your items (toys, books, clothes) are packed into one giant box. Finding something specific requires searching through the entire box. Changes or updates to one item may affect the entire box.
+
-Microservices Architecture:
-- Your items are organized into several smaller boxes, each containing similar items (toys in one box, books in another, clothes in another). Finding something specific is easier because you know which box to look in. Changes or updates to one type of item (e.g., toys) don’t affect the other box.
+**Monolithic Architecture:**
-Same going to happen in software development. Instead of all-in-one (one big chunk of code) software designs called monolithic architectures, microservices break things down into smaller, more manageable parts, making it easier to develop, update, and scale software.
+- Imagine all your items (toys, books, clothes, etc.) are stored in one big box. Finding something specific can be challenging because everything is jumbled together. If you need to update or change something, you have to dig through the entire box, which can be time-consuming and error-prone.
+- Same going to happen in software development. Monolithic architectures are like one big chunk of code where all components of an application are tightly integrated. Making changes or updates to one part of the code can have unintended consequences on other parts, leading to complex and risky development and maintenance processes.
-Let’s deep dive into the differences of these 2 patterns.
+**Microservices Architecture:**
+
+- Now, imagine your items are stored in separate, labeled containers (toys in one box, books in another, clothes in a third, etc.). Finding something specific is much easier because everything is organized and accessible. If you need to update or change something, you only need to focus on the relevant container, making the process faster and more efficient.
+- Similarly, microservices architecture breaks down an application into small, independent services, each responsible for specific functionalities. This modular approach allows for faster development cycles, easier maintenance, and better scalability. Each service can be developed, deployed, and scaled independently, promoting agility and resilience in software development.
-### 1.1.1. Size and Structure
+Let’s deep dive into the differences of these 2 patterns.
-- Monolithic: One large, interconnected structure where all components of an application are tightly integrated.
-- Microservices: Composed of small, independent services, each responsible for specific functionalities of an application.
+#### 1.1.1. Size and Structure
-### 1.1.2. Development and Deployment
+- **Monolithic:** One large, interconnected structure where all components of an application are tightly integrated.
+- **Microservices:** Composed of small, independent services, each responsible for specific functionalities of an application.
-- Monolithic: Typically developed and deployed as a single unit.
-- Microservices: Each service can be developed and deployed independently, allowing for faster iteration and updates.
+#### 1.1.2. Development and Deployment
-### 1.1.3. Modification
+- **Monolithic:** Typically developed and deployed as a single unit.
+- **Microservices:** Each service can be developed and deployed independently, allowing for faster iteration and updates.
-- Monolithic: Making changes often requires modifying the entire codebase. This can be time-consuming and risky, as a change in one part of the code may inadvertently affect other parts.
-- Microservices: Each service is focused on a specific functionality, making it easier to modify and update. Changes can be made to individual services without impacting the entire application. This modular approach allows for faster development cycles and easier maintenance.
+#### 1.1.3. Modification
-### 1.1.4. Scaling
+- **Monolithic:** Making changes often requires modifying the entire codebase. This can be time-consuming and risky, as a change in one part of the code may inadvertently affect other parts.
+- **Microservices:** Each service is focused on a specific functionality, making it easier to modify and update. Changes can be made to individual services without impacting the entire application. This modular approach allows for faster development cycles and easier maintenance.
-- Monolithic: Scaling a monolithic application usually involves replicating the entire application, including components that may not require additional resources. This can lead to inefficient resource utilization.
-- Microservices: Enables granular scaling, where only the services experiencing high demand need to be scaled. This results in more efficient resource utilization and better performance scalability.
+#### 1.1.4. Scaling
-### 1.1.5. Technology Stack
+- **Monolithic:** Scaling a monolithic application usually involves replicating the entire application, including components that may not require additional resources. This can lead to inefficient resource utilization.
+- **Microservices:** Enables granular scaling, where only the services experiencing high demand need to be scaled. This results in more efficient resource utilization and better performance scalability.
-- Monolithic: Usually built using a single technology stack (e.g., one programming language, framework).
-- Microservices: Services can be built using different technologies best suited for their specific functionalities.
+#### 1.1.5. Technology Stack
-### 1.1.6. Fault Isolation and Resilience
+- **Monolithic:** Usually built using a single technology stack (e.g., one programming language, framework).
+- **Microservices:** Services can be built using different technologies best suited for their specific functionalities.
-- Monolithic: A failure in one part of the application can bring down the entire system.
-- Microservices: Faults are isolated to individual services, so a failure in one service does not necessarily impact the entire application, enhancing resilience.
+#### 1.1.6. Fault Isolation and Resilience
-### 1.1.7. Data Management
+- **Monolithic:** A failure in one part of the application can bring down the entire system.
+- **Microservices:** Faults are isolated to individual services, so a failure in one service does not necessarily impact the entire application, enhancing resilience.
-- Monolithic: Typically uses a single database shared by all components, which can lead to data coupling and scalability challenges.
-- Microservices: Each service can have its own database, allowing for better data isolation and scalability.
+#### 1.1.7. Data Management
-### 1.1.8. Testing
+- **Monolithic:** Typically uses a single database shared by all components, which can lead to data coupling and scalability challenges.
+- **Microservices:** Each service can have its own database, allowing for better data isolation and scalability.
-- Monolithic: Testing can be complex and time-consuming, as changes may impact multiple functionalities.
-- Microservices: Testing can be more focused and granular, with each service tested independently, facilitating easier debugging and maintenance.
+#### 1.1.8. Testing
-### 1.1.9. Team Organization
+- **Monolithic:** Testing can be complex and time-consuming, as changes may impact multiple functionalities.
+- **Microservices:** Testing can be more focused and granular, with each service tested independently, facilitating easier debugging and maintenance.
-- Monolithic: Development teams often work on the same codebase, leading to potential conflicts and dependencies.
-- Microservices: Teams can be organized around individual services, allowing for greater autonomy and faster development cycles.
+#### 1.1.9. Team Organization
-### 1.1.10. Communication and Integration
+- **Monolithic:** Development teams often work on the same codebase, leading to potential conflicts and dependencies.
+- **Microservices:** Teams can be organized around individual services, allowing for greater autonomy and faster development cycles.
-- Monolithic: Communication between different components typically occurs through function or method calls within the same codebase.
-- Microservices: Communication between services usually happens over network protocols like HTTP or message queues, promoting loose coupling and interoperability.
+#### 1.1.10. Communication and Integration
+- **Monolithic:** Communication between different components typically occurs through function or method calls within the same codebase.
+- **Microservices:** Communication between services usually happens over network protocols like HTTP or message queues, promoting loose coupling and interoperability.
-# 2. Developing a Microservice application
+## 2. Developing a Microservice application
- Great! Now that we have a clear understanding of microservices, let’s embark on developing a simple microservice project.
@@ -83,7 +86,8 @@ Let’s deep dive into the differences of these 2 patterns.
- Creating a microservice application involves multiple steps. Let’s navigate through them methodically, one step at a time.
-## 2.1. Developing service registry
+### 2.1. Developing service registry
+
- A service registry, like Eureka Server, plays a pivotal role in managing the dynamic nature of microservice architectures.
- The Service Registry serves as a centralized repository for storing information about all the available services in the microservices architecture. This includes details such as IP addresses, port numbers, and other metadata required for communication.
- When a microservice instance (like expense or category) starts up, it registers itself with the Service Registry.
@@ -94,11 +98,11 @@ Let’s deep dive into the differences of these 2 patterns.
- So, Let’s create a service registry for our application.
-### 2.1.1. Create a spring boot project as below.
+#### 2.1.1. Create a spring boot project as below.
-
+
-### 2.1.2. Make Changes in Your application.properties File.
+#### 2.1.2. Make Changes in Your application.properties File.
```
# application.properties
@@ -110,21 +114,19 @@ spring.application.name=service-registry
# If you want you can change
server.port=8761
-# Disables the Eureka client's capability to fetch the registry
+# Disables the Eureka client's capability to fetch the registry
# of other services from the Eureka server, as it is not acting as a Eureka client.
eureka.client.fetch-registry=false
-# Disables the Eureka client's registration with the Eureka server.
-# Since this application is the Eureka server itself,
+# Disables the Eureka client's registration with the Eureka server.
+# Since this application is the Eureka server itself,
# it does not need to register with any other Eureka server.
eureka.client.register-with-eureka=false
```
-### 2.1.2. Update ServiceRegistryApplication.java file
-
-```
-// ServiceRegistryApplication.java
+#### 2.1.2. Update ServiceRegistryApplication.java file
+```java title="ServiceRegistryApplication.java"
@SpringBootApplication
@EnableEurekaServer
public class ServiceRegistryApplication {
@@ -136,28 +138,26 @@ public class ServiceRegistryApplication {
}
```
-
+
You can see that under ‘Instances currently registered with Eureka’, it displays a message “No instances available”. Because none of the microservices in our architecture have registered themselves with the Eureka Server.
+### 2.2. Create our first microservice: CATEGORY-SERVICE
-## 2.2. Create our first microservice: CATEGORY-SERVICE
+#### 2.2.1. Create a spring boot project as below.
-### 2.2.1. Create a spring boot project as below.
+
-
+#### 2.2.2. Add @EnableDiscoveryClient in CategoryServiceApplication class
-### 2.2.2. Add @EnableDiscoveryClient in CategoryServiceApplication class
-
-```
+```java title="CategoryServiceApplication.java"
@SpringBootApplication
@EnableDiscoveryClient
public class CategoryServiceApplication {
@@ -168,407 +168,403 @@ public class CategoryServiceApplication {
}
```
+
+ 
Then check the endpoints using postman to ensure that everything is working cool.
-
-
+
-## 2.3. Create our second microservice: EXPENSE-SERVICE
+
-### 2.3.1. Create a spring boot project as below.
+### 2.3. Create our second microservice: EXPENSE-SERVICE
-
+#### 2.3.1. Create a spring boot project as below.
-### 2.3.2. Add @EnableDiscoveryClient in CategoryServiceApplication class
+
-```
-@SpringBootApplication
-@EnableDiscoveryClient
-public class ExpenseServiceApplication {
-
- public static void main(String[] args) {
- SpringApplication.run(ExpenseServiceApplication.class, args);
- }
+#### 2.3.2. Add @EnableDiscoveryClient in CategoryServiceApplication class
-}
-```
-
-### 2.3.3. Configure application.yml file
-
-```
-spring:
-# This name is used for identifying the application in the environment
- application:
- name: expense-service
-
-# MongoDB database configuration.
-# Make sure you have created the database, before running the application
- data:
- mongodb:
- host: 127.0.0.1
- port: 27017
- database: expense_service
-
-# The port on which the Spring Boot application will listen for incoming HTTP requests
-server:
- port: 9000
-
-# The URL of the Eureka Server where the application will register itself for service discovery.
-eureka:
- client:
- serviceUrl:
- defaultZone: http://localhost:8761/eureka/
-```
+ ```java title="ExpenseServiceApplication.java"
+ @SpringBootApplication
+ @EnableDiscoveryClient
+ public class ExpenseServiceApplication {
-### 2.3.4. Create expense entity
+ public static void main(String[] args) {
+ SpringApplication.run(ExpenseServiceApplication.class, args);
+ }
-```
-@Document(collection = "expenses")
-@Data
-@Builder
-public class Expense {
-
- @Id
- private String id;
- private String description;
- private double amount;
- private LocalDate date;
- private String categoryId;
+ }
+ ```
+
+#### 2.3.3. Configure application.yml file
+
+ ```yml title="application.yml"
+ spring:
+ # This name is used for identifying the application in the environment
+ application:
+ name: expense-service
+
+ # MongoDB database configuration.
+ # Make sure you have created the database, before running the application
+ data:
+ mongodb:
+ host: 127.0.0.1
+ port: 27017
+ database: expense_service
+
+ # The port on which the Spring Boot application will listen for incoming HTTP requests
+ server:
+ port: 9000
+
+ # The URL of the Eureka Server where the application will register itself for service discovery.
+ eureka:
+ client:
+ serviceUrl:
+ defaultZone: http://localhost:8761/eureka/
+ ```
+
+#### 2.3.4. Create expense entity
+
+ ```java title="Expense.java"
+ @Document(collection = "expenses")
+ @Data
+ @Builder
+ public class Expense {
+ @Id
+ private String id;
+ private String description;
+ private double amount;
+ private LocalDate date;
+ private String categoryId;
-}
-```
+ }
+ ```
-### 2.3.5. Create dtos for send Api responses and accept expense details
+#### 2.3.5. Create dtos for send Api responses and accept expense details
-```
-@Data
-@Builder
-public class ApiResponseDto
+ 
- Let’s check endpoints for confirmation.
-
+ 
- Done. We have created 2 microservices successfully. Let’s move to next step.
- Imagine the scenario, creating an expense, before saving expenses in the database, it’s crucial to validate that the category ID provided is valid, meaning it exists in the category table. However, the Expense Service lacks direct access to category information, as categories are managed by the Category Service. This necessitates communication between the two services.
-
-## 2.4. Communication between microservices
+### 2.4. Communication between microservices
- Before persisting the expense data, the Expense Service needs to validate the category ID present in the CategoryRequestDto.
- To verify the category ID’s validity, the Expense Service communicates with the Category Service. It sends a request containing the category ID to the Category Service.
@@ -577,126 +573,124 @@ public class ExpenseController {
- OpenFeign integrates seamlessly with Spring Cloud, providing additional features for service discovery and load balancing.
- Let’s see how expense service going to interact with category service using OpenFeign
-### 2.4.1. Add OpenFeign dependency in pom.xml
+#### 2.4.1. Add OpenFeign dependency in pom.xml
- Add below dependency in expence-service pom.xml.
-```
- @FeignClient: This annotation marks the interface as a Feign client. It specifies the name of the target microservice ("CATEGORY-SERVICE"). Feign will use this name to locate the service within the service registry.
-- CategoryFeignInterface: The interface definition for the Feign client. It declares methods that will be used to make HTTP requests to the Category Service.
-- Use the same method name, parameters you have used in the category controller in the category-service. Make sure the defined method’s implementation is available in the category-service. I have implemented the getCategoryById method the category-service. Recall it again.
+- **`@FeignClient`:** This annotation marks the interface as a Feign client. It specifies the name of the target microservice ("CATEGORY-SERVICE"). Feign will use this name to locate the service within the service registry.
+- **`CategoryFeignInterface`:** The interface definition for the Feign client. It declares methods that will be used to make HTTP requests to the Category Service.
+- Use the same method name, parameters you have used in the category controller in the category-service. Make sure the defined method’s implementation is available in the category-service. I have implemented the `getCategoryById` method the category-service. Recall it again.
+#### 2.4.3. Update ExpenseServiceApplication.java
-### 2.4.3. Update ExpenseServiceApplication.java
+ ```java title="ExpenseServiceApplication.java"
+ @SpringBootApplication
+ @EnableDiscoveryClient
+ @EnableFeignClients
+ public class ExpenseServiceApplication {
-```
-@SpringBootApplication
-@EnableDiscoveryClient
-@EnableFeignClients
-public class ExpenseServiceApplication {
+ public static void main(String[] args) {
+ SpringApplication.run(ExpenseServiceApplication.class, args);
+ }
- public static void main(String[] args) {
- SpringApplication.run(ExpenseServiceApplication.class, args);
- }
+ }
+ ```
-}
-```
-- @EnableFeignClients annotation enables the Feign client in the Spring Boot application. It scans the classpath for interfaces annotated with @FeignClient and generates proxy implementations for them. These proxies are used to make HTTP requests to other microservices or external APIs.
+- `@EnableFeignClients` annotation enables the Feign client in the Spring Boot application. It scans the classpath for interfaces annotated with `@FeignClient` and generates proxy implementations for them. These proxies are used to make HTTP requests to other microservices or external APIs.
+#### 2.4.4. Implement addExpense method in expense service
-### 2.4.4. Implement addExpense method in expense service
+ ```java title="ExpenseServiceImpl.java"
+ @Component
+ public class ExpenseServiceImpl implements ExpenseService{
-```
-@Component
-public class ExpenseServiceImpl implements ExpenseService{
+ @Autowired
+ private ExpenseRepository expenseRepository;
- @Autowired
- private ExpenseRepository expenseRepository;
+ @Autowired
+ private CategoryFeignService categoryFeignService;
- @Autowired
- private CategoryFeignService categoryFeignService;
+ @Override
+ public ResponseEntity
-
-
-- In wrapping up our discussion on microservices, there’s one critical aspect left to address: the challenge of accessing microservices individually via their own port numbers. This approach becomes impractical as the number of microservices, or instances thereof increases. That’s precisely where an API gateway steps in.
+ 
+ 
+- In wrapping up our discussion on microservices, there’s one critical aspect left to address: the challenge of accessing microservices individually via their own port numbers. This approach becomes impractical as the number of microservices, or instances thereof increases. That’s precisely where an API gateway steps in.
-## 2.5. Developing API gateway
+### 2.5. Developing API gateway
- Imagine having numerous microservices or multiple instances of a single microservice scattered across your architecture. Directly accessing each one via its unique port number would result in complexity and maintenance headaches. An API gateway acts as a centralized entry point for clients, providing a unified interface to access the various microservices.
- An API gateway acts as a centralized entry point for clients, providing a unified interface to access the various microservices.
@@ -705,92 +699,93 @@ public class ExpenseServiceImpl implements ExpenseService{
- Load Balancing: The API gateway can distribute incoming requests across multiple instances of a microservice, ensuring optimal resource utilization and high availability.
- Security: Centralized authentication, authorization, and security policies can be enforced at the API gateway, safeguarding the entire system from unauthorized access and attacks.
- Monitoring and Analytics: By serving as a centralized point of contact, the API gateway facilitates comprehensive monitoring, logging, and analytics of incoming and outgoing traffic, providing valuable insights into system performance and usage patterns.
-- Now let’s see how we can develop an Api-gateway for our application.
-### 2.5.1. Create spring project
+Now let’s see how we can develop an Api-gateway for our application.
-
+#### 2.5.1. Create spring project
-### 2.5.2. Add @EnableDiscoveryClient annotation ApiGatewayApplication.java
+- Create a spring boot project as below.
+ 
-```
-@SpringBootApplication
-@EnableDiscoveryClient
-public class ApiGatewayApplication {
+#### 2.5.2. Add @EnableDiscoveryClient annotation ApiGatewayApplication.java
- public static void main(String[] args) {
- SpringApplication.run(ApiGatewayApplication.class, args);
- }
-
-}
-```
+ ```java title="ApiGatewayApplication.java"
+ @SpringBootApplication
+ @EnableDiscoveryClient
+ public class ApiGatewayApplication {
-### 2.5.3. Configure application.yml file
+ public static void main(String[] args) {
+ SpringApplication.run(ApiGatewayApplication.class, args);
+ }
-```
-# The port number (8080) on which the API gateway will listen for incoming requests.
-server:
- port: 8080
-
-# The name of the Spring Boot application.
-spring:
- application:
- name: api-gateway
- cloud:
- gateway:
- mvc:
-# Enables discovery-based routing. When enabled, Spring Cloud Gateway will automatically discover
-# routes for registered services using service discovery
- discovery:
- locator:
- enabled: true
-# Defining the routing rules for accessing microservices
- routes:
- - id: category-service
- uri: lb://CATEGORY-SERVICE
- predicates:
- - Path=/category-service/**
- filters:
- - StripPrefix=1
-
- - id: expense-service
- uri: lb://EXPENSE-SERVICE
- predicates:
- - Path=/expense-service/**
- filters:
- - StripPrefix=1
-
-# The URL of the Eureka Server where the API gateway will register itself and discover other services.
-eureka:
- client:
- serviceUrl:
- defaultZone: http://localhost:8761/eureka/
-```
+ }
+ ```
+
+#### 2.5.3. Configure application.yml file
+
+ ```yml title="application.yml"
+ # The port number (8080) on which the API gateway will listen for incoming requests.
+ server:
+ port: 8080
+
+ # The name of the Spring Boot application.
+ spring:
+ application:
+ name: api-gateway
+ cloud:
+ gateway:
+ mvc:
+ # Enables discovery-based routing. When enabled, Spring Cloud Gateway will automatically discover
+ # routes for registered services using service discovery
+ discovery:
+ locator:
+ enabled: true
+ # Defining the routing rules for accessing microservices
+ routes:
+ - id: category-service
+ uri: lb://CATEGORY-SERVICE
+ predicates:
+ - Path=/category-service/**
+ filters:
+ - StripPrefix=1
+
+ - id: expense-service
+ uri: lb://EXPENSE-SERVICE
+ predicates:
+ - Path=/expense-service/**
+ filters:
+ - StripPrefix=1
+
+ # The URL of the Eureka Server where the API gateway will register itself and discover other services.
+ eureka:
+ client:
+ serviceUrl:
+ defaultZone: http://localhost:8761/eureka/
+ ```
- id: category-service — This is an identifier for the route. It’s used internally within the API gateway configuration to refer to this specific route. It doesn’t have any significance outside of the configuration context.
- uri: Specifies the URI (Uniform Resource Identifier) of the target microservice.
- lb://: This prefix indicates that load balancing should be applied to the target URI. The lb stands for "load balancer".
- CATEGORY-SERVICE: This is the logical name of the microservice registered with the service registry (Eureka). Use the same name which displayed in the eureka server.
- Predicates are conditions that must be met for a request to match this route and be forwarded to the target microservice.
-- - Path=/category-service/: This predicate specifies that requests must have a path starting with "/category-service/" followed by any additional path segments. The "**" wildcard matches any number of additional path segments. You can use any prefix as you wish.
+- - Path=/category-service/: This predicate specifies that requests must have a path starting with "/category-service/" followed by any additional path segments. The "\*\*" wildcard matches any number of additional path segments. You can use any prefix as you wish.
- Filters are applied to requests before they are forwarded to the target microservice. They can modify request headers, paths, or payloads, among other things.
- - StripPrefix=1: This filter removes one path segment, effectively stripping "/category-service" from the request path. This is necessary because the routing predicate matches requests starting with "/category-service/", but the target microservice expects requests without this prefix.
-
-### 2.5.4. Test the application
+#### 2.5.4. Test the application
- For instance, let’s say you want to retrieve all expenses. You would typically use the URI localhost:8080/expense-service/expense/all.
- It matches the incoming request against the defined routes based on the configured predicates. In this case, it identifies that the request path starts with “/expense-service/”, indicating that it should be directed to the expense service.
- Before forwarding the request to the expense service, the API gateway rewrites the URI to match the expected format of the microservice. Since the expense service expects requests without the “/expense-service” prefix, the API gateway removes this prefix from the URI.
- Once the URI is properly formatted, the API gateway forwards the request to the identified microservice. In this example, it sends the request to the expense service, ensuring that it reaches the correct endpoint (“/expense/all”).
-Let’s check this in post man.
-
+
+ Let’s check this in post man.
-
-
+ 
+ 
Throughout this journey, we explored the core concepts of microservices, compared them to monolithic architectures, to developing microservices.
-Thanks for taking the time to read my article.
+Thanks for taking the time to read our article.
\ No newline at end of file
diff --git a/dsa-solutions/lc-solutions/0000-0099/0017-letter-combinations-of-a-phone-number.md b/dsa-solutions/lc-solutions/0000-0099/0017-letter-combinations-of-a-phone-number.md
deleted file mode 100644
index 26cf596b7..000000000
--- a/dsa-solutions/lc-solutions/0000-0099/0017-letter-combinations-of-a-phone-number.md
+++ /dev/null
@@ -1,315 +0,0 @@
----
-id: letter-combinations-of-a-phone-number
-title: Letter Combinations of a Phone Number (LeetCode)
-sidebar_label: 0017 Letter Combinations of a Phone Number
-tags:
- - Back Tracking
- - Mapping
- - String
-description: The problem requires generating all letter combinations corresponding to given digits (2-9). The solution utilizes backtracking to explore all combinations efficiently, employing a recursive approach in Java.
----
-
-## Problem Description
-
-| Problem Statement | Solution Link | LeetCode Profile |
-| :----------------------------------------------------------------------------------------------------------- | :------------------------------------------------------------------------------------------------------------------------------------------ | :------------------------------------------------- |
-| [Letter Combinations of a Phone Number](https://leetcode.com/problems/Letter Combinations of a Phone Number/) | [Letter Combinations of a Phone Number Solution on LeetCode](https://leetcode.com/problems/Letter Combinations of a Phone Number/solutions/5055810/video-two-pointer-solution/) | [gabaniyash846](https://leetcode.com/u/gabaniyash846/) |
-
-### Problem Description
-
-## Problem Statement:
-Given a string containing digits from 2-9 inclusive, return all possible letter combinations that the number could represent. Return the answer in any order.
-
-### Examples
-
-#### Example 1
-
-- **Input:** `digits = "23"`
-- **Output:** `["ad","ae","af","bd","be","bf","cd","ce","cf"]`
-
-#### Example 2
-
-- **Input:** `digits = ""`
-- **Output:** `[]`
-
-
-#### Example 3
-
-- **Input:** `2`
-- **Output:** `["a","b","c"]`
-
-### Constraints:
-- `0 ≤ digits.length ≤ 4`
-- `0 ≤ digits.length ≤ 4digits[𝑖]`
-- `digits[i] is a digit in the range ['2', '9'].`
-- `A mapping of digits to letters (similar to telephone buttons) is given below. Note that 1 does not map to any letters.`
-
-### Approach
-
-1. **Mapping Digits to Letters:**
- - Define a mapping of digits to their corresponding letters, similar to telephone buttons.
-
-2. **Backtracking Function:**
- - Define a recursive backtracking function to generate all possible combinations.
- - The function takes four parameters:
- - `index`: The current index in the digits string.
- - `path`: The current combination of letters.
- - If the index is equal to the length of the digits string, it means we have reached the end of a combination, so we add it to the result list.
- - Otherwise, for each letter corresponding to the current digit, we append it to the current combination and recursively call the function with the next index.
- - After the recursive call, we remove the last character from the combination (backtracking).
-
-3. **Base Case:**
- - If the length of the current combination is equal to the length of the input digits string, we add the combination to the result list.
-
-4. **Main Function:**
- - Initialize an empty list to store the combinations.
- - Call the backtracking function with the initial index set to 0 and an empty string as the initial combination.
- - Return the list of combinations.
-
-This approach ensures that all possible combinations are generated using backtracking, and the result is returned in the desired format.
-
-### Solution Code
-#### Python
-
-```python
-class Solution:
- def letterCombinations(self, digits: str) -> List[str]:
- if not digits:
- return []
-
- digit_to_letters = {
- '2': 'abc',
- '3': 'def',
- '4': 'ghi',
- '5': 'jkl',
- '6': 'mno',
- '7': 'pqrs',
- '8': 'tuv',
- '9': 'wxyz'
- }
-
- def backtrack(index, path):
- if index == len(digits):
- combinations.append(path)
- return
- for letter in digit_to_letters[digits[index]]:
- backtrack(index + 1, path + letter)
-
- combinations = []
- backtrack(0, '')
- return combinations
-```
-
-#### Java
-
-```java
-import java.util.ArrayList;
-import java.util.HashMap;
-import java.util.List;
-import java.util.Map;
-
-public class Solution {
- private Map