I’ve been thinking a lot lately about what “product-market fit” actually means in practice, beyond the way it gets used as a buzzword in pitch decks and strategy decks alike.

The term gets credited to Marc Andreessen, who described it simply as being in a good market with a product that can satisfy that market. Sean Ellis later offered a more testable version of the idea: survey your users, and if at least 40% say they’d be “very disappointed” without your product, you’re probably onto something real.

But the more I sit with it, the more I think the interesting part isn’t the definition. It’s what product-market fit is not. It’s not a launch date. It’s not a feature list. It’s not even a strong quarter of adoption numbers. It’s the state where a market’s real, specific need and your product’s real, specific answer to that need line up so well that growth stops requiring force.

Customers pull the product toward them instead of you pushing it at them. Usage compounds through word of mouth instead of persuasion. Retention holds instead of leaking.

And crucially, fit is rarely uniform. A product can have strong fit in one segment, one region, or one use case, and weak or no fit in another — because “the market” is never really one market. It’s a collection of very different people with very different problems, wearing the same label.

That’s the part I find most relevant to how we build things in commercial real estate technology. A workflow that feels indispensable to a facilities team in one region can feel like noise to a similar team somewhere else, not because the underlying problem is different, but because the shape of the problem, the vendors involved, the approval chains, the currencies, the regulatory quirks, the way spend gets tracked and reported, is different.

Product-market fit has to be pursued region by region and workflow by workflow, not assumed to travel automatically just because something worked well somewhere else. A feature that already has fit in one market doesn’t arrive with fit anywhere else. It has to earn it again, against the realities of local vendor ecosystems, local reporting expectations, and local ways of working.

If there’s one thing I’d want other product and CRE teams to take from this, it’s that product-market fit is less a box you check once and more a discipline you keep practicing; market by market, segment by segment, as the ground underneath your users keeps shifting. The moment you treat it as “done,” it usually isn’t.

What has your experience been with finding fit across different markets or regions? I’d genuinely like to hear how others have approached it.

What I Keep in Mind About Token Usage as a Product Leader

A few years ago, I didn’t need to think about tokens. Now, every AI feature I ship has a hidden line item running underneath it — cost, latency, and quality all tied to how many tokens flow in and out. I’ve learned that if I don’t own this as a product decision, it gets made for me by default, usually in a way I don’t like.

Here’s what I actually keep top of mind.

I treat tokens as currency, not a technical detail

A token is roughly three-quarters of a word. Every prompt I send, every document retrieved, every turn of conversation history, every tool call and its result — all of it gets counted, and I pay for what goes in and what comes out.

I’ve stopped thinking of this as an engineering concern. It’s directly tied to three things I’m accountable for:

Cost. My AI feature doesn’t have one cost-per-use, it has a distribution. A user who pastes in a ten-page document costs me 50x more than one who types a one-line question. If my pricing doesn’t account for that variance, I’m quietly subsidizing my heaviest users.

Latency. More tokens in, more tokens out, more time waiting. A feature that feels instant at 200 tokens can feel broken at 2,000. I treat latency as a design decision, not just an infra metric — it’s how much context and output quality I’m willing to trade for speed.

Quality ceiling. Context windows are finite. If a feature needs to reason over a long document, a chat history, and tool results at once, I can hit real limits on what the model attends to well, not just what technically fits.

I set token budgets the same way I set any other spec

I don’t leave this to engineering to figure out downstream. I treat it as a product requirement from day one.

• I set a token budget per user action, the same way I’d set a latency SLA. If a “summarize this” feature is burning 8,000 tokens a call, I want to know if that’s intentional or scope creep before it ships.
• I track cost per active user, not just cost per API call. A power user hitting the feature 200 times a day looks nothing like an occasional user, and my pricing tiers need to reflect that or my margins erode silently.
• I ask for token usage to be instrumented like any other metric — tokens in, tokens out, cost per session, latency by token count. If I can’t see it on a dashboard, I find out there’s a problem when the bill lands, not before.

The levers I actually weigh

Every one of these is a real tradeoff, and part of my job is deciding which side of it I want.

• Model tiering. Not every task needs the flagship model. I push teams to route simple classification or extraction to a smaller, cheaper model and reserve the expensive one for tasks that genuinely need the reasoning. This is often the single biggest cost lever available.
• Context management. Do we send the full conversation history every call, or summarize older turns? Retrieve the whole document or just the relevant chunk? I treat this as product design, because it directly shapes what the AI “remembers” and how it behaves — not just what it costs.
• Prompt caching. If a system prompt or reference document gets reused across calls, caching it can meaningfully cut cost and latency. I ask engineering directly whether this is in play before assuming it is.
• Streaming vs. batching. Streaming a response token-by-token makes a slow response feel fast, even when total token count hasn’t changed. It’s often close to free to implement and it changes perceived quality more than almost anything else I can do.
• Output constraints. Asking for a structured, bounded response instead of an open-ended one is one of the simplest ways I control cost and latency at once — and it usually improves quality, because the model isn’t padding.

Why I put this on the roadmap, not just in eng standups

The uncomfortable truth I’ve had to sit with: a lot of AI features ship with no real token strategy, and it works fine until usage scales. Then cost-per-user quietly outpaces revenue-per-user, or a “premium” feature turns out to be a loss leader I priced wrong. By the time that shows up in a P&L review, it’s a much harder conversation than it would have been at the design stage.

So the questions I try to ask early, every time:

• What does this cost at 10x usage, not just at launch volume?
• What’s our latency budget, and what are we trading to hit it?
• Is this feature’s value proportional to its token cost, or are we burning budget on context the model doesn’t even need?

Tokens aren’t just an infrastructure detail to me anymore. They’re a product constraint, a pricing lever, and increasingly, a place where the leaders who understand this well enough to design around it are going to outrun the ones who just react to the invoice.

What is serverless architecture?

Serverless architecture does not mean that there is no server. Serverless architecture is a cloud computing model where developers write and deploy code in response to specific events, without having to manage the underlying infrastructure. The cloud provider (AWS, Azure, Google Cloud) spins up resources to run the code on demand, then scales them down or shuts them off when the function finishes. User only pay for the resources used, not for idle servers.

Here we are taking an example of Starbucks ordering process and trying to explain from the lenses of serverless architecture. All services used in this architecture will be considered deployed on AWS lambda functions. Each service will be using its own database as a microservices pattern.

Starbucks order process

Here’s a breakdown of how a Starbucks order might be implemented using serverless architecture:

• Mobile app or website: The customer places an order through the Starbucks application on mobile or website.
• API Gateway: This serverless component receives the order request and routes it to the order service.
• Order Service: This lambda function validates the order details. It communicates with inventory service to checks inventory levels and put the order in queue service.
• Inventory Service: This lambda function checks inventory levels in system that we have enough product and ingredients to make this order.

• Payment Service: This lambda function handles payment authorization and interact with third-party PSPs (Payment Service Providers) like PayPal, Visa etc. to finalize the transaction.
• Notification Service: Payment function talks to notification service and customer receives notifications through the app or via text message.
• Analytical Platform: The payment function sends transaction details to the analytics platform.

At Starbucks, cashier takes your order and process payment. Then he writes the customer’s name on a coffee cup to pass it to barista to prepare coffee. Barista picks up the cup and makes coffee. Customers get their coffee at the counter.

The cashier takes the order and does not wait for the first order for completion. It takes another order and put all the orders in queue. Similarly, barista put the completed coffee on the counter and prepare the next order.

All these steps work in asynchronous manner and operates independently. Message queue plays an important role over here. Here is updated process flow diagram with queue service.

Pros of Serverless Architecture:

Here are some of the major advantages of using serverless architecture.

1. Faster Development and Deployment: With serverless architecture there is no need to manage servers or infrastructure. It gives more time to focus on writing code and building features. Deploy changes and updates on the fly, without worrying about server downtime or maintenance.
2. Scalability and Cost Efficiency: Resources automatically scale up or down based on demand, ensuring optimal performance without paying for idle servers. You only pay for the resources your lambda functions use, leading to significant cost savings. You do not need to invest in and maintain your own servers or hardware.
3. Increased Productivity: Developer can focus more on code logic and business functionality, in spite of thinking about server management. Develop and test new features quickly and easily without worrying about complex infrastructure dependencies.
4. Enhanced Reliability and Security: Cloud providers manage the underlying infrastructure, ensuring high availability and resilience. Developers can concentrate on securing their code logic without managing server security configurations.

Cons of Serverless Architecture

Serverless architecture isn’t perfect for every situation. There are various drawbacks also with this.

1. Cold Starts: The first time a function is invoked after a period of inactivity, it can experience a delay due to the time needed to spin up resources. This can impact performance-sensitive applications.

2. Database Issues: Some databases have connection limits, and opening a new connection for each Lambda invocation may lead to reaching these limits quickly.

3. Potential Cost Overruns: While cost-efficient for many use cases, unpredictable or high-volume usage can lead to unexpected costs.

4. Limited Control and Customization: Developers have less control over the underlying infrastructure and runtime environment, which can limit customization options.

5. State Management: Serverless lambda functions are often stateless, meaning they don’t maintain data between invocations.

6. Long-Running Processes: Serverless lambda functions typically have timeout limits, making them less suitable for tasks that require extended execution times.

Functional Requirements:

1. Application type: What type of application Telegram is? (Telegram is available on mobile devices, desktops, laptops and web browser)
2. Content Type:

• What type of content user share on Telegram? (Telegram is used for instant text messaging between two users of Telegram.)
• Can user share other content as well on Telegram? If yes, then what is the limit if the size of the files? (Telegram enables users to share a wide range of files, including documents, photos, videos, and audio, with up to 2GB file size per message.)
• Can multiple users chat on Telegram? (Yes, Telegram supports large group chat and can accommodate up to 200,000 members. This feature makes it ideal for communities, organizations, and large-scale discussions.)
• Can user broadcast the message to bigger audience? (Telegram’s channels serve as one-to-many broadcast platforms, allowing users to disseminate messages to a large audience of subscribers.)

3. Notification status: Does user get the notification of sending, receiving and delivering the messages? (Yes, Telegram messages shows it by ticks which can explain below)

• One Tick: A single tick next to your message indicates that the message has been successfully delivered to Telegram’s servers. This means that the message has been sent to the cloud and is ready to be delivered to the recipient’s device. However, it doesn’t necessarily mean that the recipient has seen the message.
• Two Ticks: Two ticks next to your message indicate that the message has been delivered to the recipient’s device and recipient has opened the chat containing the message. This means that the message has been displayed on the recipient’s screen, but it doesn’t necessarily mean that the recipient has read the message.
• No Ticks: If there are no ticks next to your message, it means that the message is still pending. This could be because the recipient’s device is offline, they have network connectivity issues, or they have blocked you.

4. Audio and video calls: Can user make audio and video calls on Telegram? (Telegram offers high-quality voice and video calling capabilities, allowing users to engage in real-time conversations with individuals or groups.)

5. Privacy of messages: Does Telegram self-destructs the messages for privacy? (Telegram’s Secret Chats feature incorporates self-destructing messages, enabling users to set a timer for messages to automatically disappear after a specified duration.)

Non-Functional Requirements:

1. Performance: Telegram should be fast. There should be minimal latency when user send and receive the messages.
2. Scalability: Application should accommodate if user base is increasing. The performance of the application should not degrade with increased number of users or traffic.
3. Reliability: Application should be reliable and should deliver the messages with full security and privacy.
4. Security: Telegram should prioritize user security, safeguarding user data and protecting against unauthorized access or data breaches. Strong encryption and robust security measures should be implemented.
5. Usability: Telegram application should be user friendly and easy to use.
6. Internationalization: Telegram should support multiple languages and cater to users worldwide. It should be localized and adapted to different cultures and regions.
7. Update and Maintenance: Application should be easy to maintain and update, allowing developers to fix bugs, implement new features, and address security vulnerabilities without disrupting user experience.

Scale of application:

1. Total Users: Telegram has 250 million daily active users (DAU) as of 2023.
2. Message Volume: Telegram process over 1 billion messages per day.
3. Data Usage: Telegram’s data usage is estimated to be around 50 petabytes per month.
4. Geographic Reach: Telegram has a global presence with users in over 200 countries and territories.

Use cases of Telegram:

Here we are taking two use cases of Telegram. First use case is chat between two users and second use case is group chatting.

One to one user: Telegram has multiple users and they registered in Telegram with their phone number. A user sends the message to the other recipient user. As soon as message goes, it shows one tick which means the message has been successfully delivered to Telegram server. If the recipient user is offline, then it will not deliver the message to that user. It will stay in the queue service and will wait for that recipient user to be available. We can see the last seen time stamp on the recipient user information. As soon as the recipient user will be available, then that message will be delivered on the recipient user’s device. On first user application, now the single tick will change to the double tick which means that message has been delivered to the recipient’s device and recipient has opened the chat containing the message.

Group Chat between multiple users: Telegram facilitate communication and collaboration among a vast number of participants by group chat functionality. User can engage with lots of members in real time by group chat.

High Level System Design of Telegram:

There are multiple components which make Telegram works. These components are:

1. Devices for Telegram
2. Load balancer
3. Services which play an important role in Telegram functionality

• User Service: This service stores user information and updates
• Session Service: This service contains the session information about the users.
• Group Service: This service stores information about the group chat users.
• Last Seen Service: This service stores information about the status of the user whether user is online or offline.
• Message Queue Service: It contains all the messages which user sends and stores it until the recipient user is online.
• Push Notification Service: As soon as user get online, this service push notification on recipient device.
• Chat Service: It stores all the messages which user share on Telegram. it contains the text messages, audio and video files.

4. Database to store information: Here we are taking microservices approach where each service has its own respective database.

Telegram can be accessed on browser and phone devices. It goes through CDN layer where, it can handle large spikes in traffic, guaranteeing that Telegram remains responsive and reliable even during large chat volume. Traffic distributes through load balancer to the Telegram server. The microservices take the input and reach to the respective database to return the message back. It's a very high-level diagram and we are not explaining the queue service functionality in detail here.

Sequence Diagram of Telegram:

You can see the detailed flow diagram that can explain that how the message flows from server to the other user device.

Please zoom the diagram to understand the flow.

In conclusion Telegram’s system design is a well-designed and scalable solution for a high-volume messaging platform. Its focus on security, privacy, and user experience has contributed significantly to its success. Overall instant messages applications like WhatsApp and Telegram have become an essential part of our digital lives, transforming the way we communicate, share information, and connect with others and evolving continuously.

Spotify is a digital music streaming service that provides access to a vast library of songs, podcasts, and other audio content. Users can listen to music from various artists and genres on demand, create playlists, and discover new music through personalized recommendations. Let's discuss the system design for Spotify.

Finding the requirements from the stakeholders.

Functional Requirements:

1. Application Type: What type of application this is? (Available on various devices and platform such as phone, laptop, smart watch, tablet and smart speaker)
2. Content Type: What content this application has? (Spotify has millions of songs/audio files)
3. Capability:

• Can we download music from this? (Yes, Limit is 10,000 songs up to 5 different devices. All devices should have same account login.)
• Can user search his desired music? (Yes, User can search the desired song, desired artist, desired podcast, desired genre of music)
• Can user control the music? (Yes, User can skip, play, pause, repeat and shuffle the music.)
• What other categories Spotify has? (Spotify has users, artists, playlists, podcasts, and radio.)
• Can user create a playlist of his favorite content? (Yes, User can edit/create/delete a playlist.
• Can we share the music on social platform? (Yes, User can integrate music with social media platform as well.)
• Do we get notifications for any new content? (Yes, User get push notification for new releases, recommendations and new update.)
• Can we get the lyrics of the song as well? (Yes, Spotify has the capability of displaying the lyrics of the song, which user is listening.)

Nonfunctional Requirements:

1. Availability: As soon as user will search the music, the music should play immediately. System should be highly available with minimum latency.
2. Throughput: Throughput should be higher. System should be capable of handling large number of users and their streaming requests without degradation in performance.
3. Usability: User interface should be intuitive, easy to navigate and visually appealing.
4. Scalability: The system should be able to handle an increasing number of users, songs, and playlists without a significant degradation in performance.
5. Compatibility: The application should be compatible with a wide range of devices, operating systems, and web browsers.
6. Offline mode performance: When in offline mode, the system should efficiently manage downloaded content, ensuring smooth playback and minimal storage requirements.
7. Internationalization and Localization: The application should support multiple languages and cultural preferences to cater to a diverse user base.
8. Error Handling: The system should provide clear and helpful error messages, guiding users in case of issues.
9. Update and Maintenance: The process of updating the application should be seamless for users, and maintenance activities should not disrupt the user experience.

Scale of application:

1. Total Users: Spotify has 551 million monthly active users as of third quarter of 2023.
2. Total Data: Spotify’s music library consists of over 82 million songs. If each song is around 3–5 MB in size, then total music data is likely in the range of 246–410 terabytes (TB). Other than that Spotify saves user data (User’s history, playlist and preferences which can be in range of tens of petabytes) and artist data (Artist’s biography, photos and tour dates which can be in range of hundreds of terabytes).

Overall, it is estimated that Spotify stores over 500 PB of data. This is a massive amount of data, and it is growing rapidly as Spotify continues to add new songs, users, and artists.

This is the detailed functional and nonfunctional requirements of Spotify. For system design we will consider the high-level design that how a user search music on the application and play that music. If you are explaining this concept in any interview, then try to constrain the problem so that you can explain in limited time.

High Level System Design of Music application like Spotify:

First, we will discuss the high-level system design of Spotify. In real case Spotify must be using different services but we are explaining it in general by taking example of AWS services.

Component 1: Devices to access Spotify

Spotify can be accessed on multiple devices. It can be accessed on desktops, phones, tablets, smart TVs, smart speakers, wearables like smart watches, gaming consoles and car systems. Users can search for the desired music on any of these devices.

Component 2: Content delivery network (CDN)

In the second component we explain the CDN layer for Spotify. Spotify uses a combination of its own CDN infrastructure and third party CDN’s such as Fastly and Akamai. Here we are taking an example of the CloudFront CDN which is from the AWS family.

CDN infrastructure is responsible for caching and delivering the static content. This content can be images, CSS and JavaScript files. It helps in reducing the latency and improving the user experience as these edge servers are strategically located around the world.

Spotify localizes the content so people can easily find Bollywood music in India, K-pop in Korea and sertanejo in Brazil. Playlists can share a theme but feature different songs in different parts of the world, so Taiwan’s hits are not the same as those in the United States.

See below for how Spotify presents a “Happy Hits” playlist in the United States, India, Taiwan and Turkey.

At the CloudFront layer we can seamlessly handle spikes in traffic and demand, guaranteeing that Spotify streaming application remains responsive and reliable even during peak usage periods. CloudFront integrates with AWS security services like AWS Shield and AWS Web Application Firewall (WAF), providing robust protection against cyberattacks and unauthorized access. This safeguards the streaming content and user data.

CDN layer supports HLS (HTTP Live Streaming), a widely used protocol for streaming media content. This enables efficient delivery of adaptive bitrate streams, ensuring optimal playback quality on various devices and network conditions.

CDN layer provides real-time monitoring tools that enable you to track streaming performance, identify potential issues, and optimize delivery.

Component 3: Load balancer

Spotify has a huge user base and it receives millions of requests at the same time from users. It uses a load balancing system to effectively distribute incoming requests across a network of backend servers, ensuring optimal performance, reliability, and scalability for its massive user base.

Spotify’s load balancing system dynamically scales up or down the number of backend servers based on real-time traffic patterns. This ensures that the system can handle spikes in demand without performance degradation. The load balancing system continuously monitors server health and performance metrics, generating alerts when potential issues arise. This allows Spotify to proactively address any problems before they impact users.

To improve performance and reduce latency, Spotify employs caching mechanisms. Caching involves storing frequently accessed content on the web server or edge servers closer to the user, reducing the need to retrieve it from the origin server each time. Spotify’s web servers implement various security measures to protect user data and prevent cyberattacks. These measures may include encryption protocols, authentication mechanisms, and vulnerability management practices.

Component 4: Spotify Web Server

When a user creates a request to search a track it goes to the spotify web server. It follows the below steps.

• The user’s device contacts a Domain Name System (DNS) server to translate the Spotify website URL into the actual IP address of the web server.
• This device establishes a TCP (Transmission Control Protocol) connection with Spotify’s web server. This connection serves as a dedicated channel for communication between the user and the server.
• The user’s device sends an HTTP (Hypertext Transfer Protocol) request to Spotify’s web server. This request contains information about the specific page or resource the user is trying to access, such as the homepage, login page, or a specific playlist.
• Spotify’s web server receives the HTTP request, processes it, and generates an HTTP response. The response contains the requested content, such as HTML code, CSS stylesheets, JavaScript files, and images.
• The user’s web browser receives the HTTP response from Spotify’s web server and begins rendering the content. User start listening to the desired track.

Component 5: Relational database (RDS) to save metadata.

RDS is a highly optimized and efficient database service that can handle large volumes of data quickly and reliably. This is important for Spotify, which needs to be able to store and retrieve metadata for its millions of songs, artists, and playlists.

It is a scalable database service, which means that it can be easily expanded to accommodate more data. RDS is a reliable database service, which means that it is unlikely to crash or lose data. This is important for Spotify, which needs to be able to access its metadata 24/7.

Here are some specific examples of how Spotify uses RDS to store and manage metadata.

• Song metadata: Spotify stores information about its songs, such as the song title, artist, album, and release date. This metadata is used to search for songs, create playlists, and recommend songs to users.
• Artist metadata: Spotify stores information about its artists, such as the artist’s name, biography, and genre. This metadata is used to create artist pages, display artist information on songs, and recommend artists to users.
• Playlist metadata: Spotify stores information about its playlists, such as the playlist name, creator, and tracks. This metadata is used to display playlists, play playlists, and recommend playlists to users.

Component 6: Storage Service (Amazon S3)

Spotify contains millions of music tracks which need to be saved somewhere. Spotify does not directly store MP3 files on its servers. Instead, it encoded the music in a proprietary format called Ogg Vorbis that is optimized for streaming. It uses many third-party tools which convert these proprietary formats to MP3 format on the fly. Here to explain a simple music file saving, we are taking the storage service S3 for example where we will store the audio files MP3 in that. When a user makes a request for a song then first it presents the metadata related to that track and then plays the specific track from S3 bucket and serves it on the user’s device.

Spotify’s storage service works by using a combination of caching and streaming.

Caching is the process of storing data temporarily in a location where it can be accessed quickly. Spotify caches songs on your device so that they can be played without having to be downloaded again each time you listen to them. This makes playback faster and smoother, especially when you’re offline.

Streaming is the process of downloading data from a server as you need it. Spotify streams songs from its servers to your device so that you can listen to them without having to download them all at once. This is useful for listening to new music or for when you don’t have enough storage space on your device.

Spotify uses a hybrid approach to storage, which means that it uses both caching and streaming to deliver the best possible listening experience. When you first listen to a song, Spotify caches it on your device. This means that you can listen to the song again without having to download it from the server. If you listen to the song again later, Spotify may check to see if there is a newer version of the song available on the server. If there is, Spotify will download the newer version and replace the cached version.

Spotify also uses streaming to deliver music that is not cached on your device. When you stream a song, Spotify downloads it from the server in small chunks as you listen to it. This means that you can start listening to a song almost immediately, even if you don’t have a lot of storage space on your device.

This is how a simple use case of searching the music on Spotify and playing that can explain through high level system design.

Pandemic. As soon as we hear this word it gives us a weird feeling. We used to watch this only in movies when the whole town get affected by a wide spread disease and scientist used to find the cure during those 90 minutes of that movie. I wish it was as simple as they generally portray in the movies. Life was going normal and we were busy in our regular life and then this disaster came and whole world get stopped.

In starting everyone was talking about a specific country who effected with this but later it reached not only to different countries but all continents. I still remember the day when in January I was in office and was chatting with my teammates about the mortality rate and effect of corona. Next day we got to know that we lost one of our office mate in this fight and our offices are now closing for the indefinite time. Now it has been 7 months and we all are used to this new norm of life where we do work from home and kids attend the remote classes.

During this situation I saw the 3D effect of Corona. Here 3D is not the three dimensional effect but it is that how people get effected differently in this situation and I divided them in three categories.

First category people were who utilized this time in improving their skills, learning new things, exploring new hobbies. Luckily those were the people who did not get impacted by this awful disease or loss of employment. Some did the soul searching during this time and figured it out that what they can do better when it comes to their work or life. On the other hand there were some people who had the other challenges to overcome like surviving in the low economy without job. There were few people in this category who were trying to neglect the seriousness of this wide spread because fortunately they were not facing it. If you are not facing this luckily, then please respect those people who are going through this.

Second category people were who faced this disease in their family. It shook them completely because it is not easy when you go through something like this. There were people who were praying to God that they can do anything to over come this disease. Few were regretting that why they took it so lightly and did not bother that how this deadly virus will gonna effect their body. They survived this storm and came back to the normal life but they will never forget these days throughout their life when they saw life and death hand in hand.

Third category people were who lost their dear ones in battling this pandemic. This was like a nightmare for them as no one thought that this type of horrendous time will come and it will take away so many lives. There were people who said final good bye to their family members on phones and family members saw this helplessly. During this time hats off to all the front line fighters who took care of everyone with full empathy but we cannot fill the void space in those families who lost their loved one.

“The life of the dead is placed in the memory of the living.” : Marcus Tullius Cicero

Exercise: Just sit back and look around you that what you have. If you are working from home, then follow the routine and along with that cherish the moments with your kids and watch them growing. Think about those people who are suffering from this disease and call them so that they will not feel alone. You can not physically support them but at least emotionally you can make them strong. Showing empathy is nothing but capacity to place oneself in another’s position. By helping each other we will overcome this situation and will come back to normal.

I think in our life a moment comes when we sit back and think that when this race will be over. Race of gaining name and fame, earning money or running behind our desires. We are not Buddha means “Awakened one” who can raise from the sleep of ignorance and start looking the true world around us. We are a normal human beings who always get busy in setting new future goals and keep chasing these goals one after another. We forget that what satisfaction taste like or feel like.

Felling satisfy does not mean that now you are not ambitious. It does not mean that you become passive and you are lacking the fire to achieve something. Contentment is very paradoxical. In current time we have not taken the contentment and happiness in the right context. Both goes hand in hand. Contentment comes naturally when you feel happiness from inside.

Setting goal and work towards it, is not wrong. Wrong is, that if you stop enjoying the moment in which you are living. In the end when you will fulfill your goal then may be that happiness will last for a while. You will feel happy that you achieved something and you are on top of the world. But soon after you will keep setting some bigger goal and keep pushing your self to achieve that. Now if you give yourself a halt and think deeply then you will realize that in process of running behind these goals, you missed so many precious moments or events. Now a then it is good to pause in our pursuit of happiness and just be happy. Time is a universally changing dimension. It always go forward. Even though we feel many time that we could have gone back to the old time and rectify so many things in our life, but it is not possible.

Human never feel satisfy. To gain the satisfaction you have to work towards it. You have to train your mind and follow few things in your life which are

Stop comparing your life with others : The easiest way to achieve the satisfaction and happiness is to stop comparing your life with other people. Human always look for the people who are more famous than themself or more richer than them. If you are considering them a positive enforcement then its fine but if you are comparing your life with them and getting depressed then you will never achieve happiness. Everyone has the different journey in the life so results can vary. There are people who are happy with less than what you have in life.

Make realistic goals: Setting goals are not wrong but one should set the realistic goals which can be achievable. When you will achieve that goal, you must have enjoyed the journey behind that because the process and journey which you spend to achieve that goal is the real one which gives you the most important experience of the life. Happiest people may not have the best of everything but they know how to make best of everything.

Appreciate the things which you have: Our life is like a deck of card and it has what life give us. You should always appreciate the things which you have because there must be so many people in this world which have lesser than what you have. We generally forget what we got in life and keep cribbing about the things which we don’t have. Appreciate people and show gratitude because it gives an immense happiness to you and the other person.

“ There are only two ways to live the life. One is as though nothing is a miracle. The other is as though everything is a miracle.”: Albert Einstein

A small exercise : Maintain a diary in which you write three most important things which you want in a year. On the last day of that year come back and check that what you get out of those three things which you thought were the most important things in your life at that moment. When you will check that you will realize that there are more things than those desirable three things which you wrote in your diary. By this you will realize that you should appreciate God for millions of other things and happiness which He provided to you. I follow this every year with my kids and family. I hope you all will also do this and enjoy your life with immense feeling of contentment and happiness.