{"id":110821,"date":"2026-05-14T15:17:27","date_gmt":"2026-05-14T09:47:27","guid":{"rendered":"https:\/\/www.guvi.in\/blog\/?p=110821"},"modified":"2026-05-14T15:17:29","modified_gmt":"2026-05-14T09:47:29","slug":"availability-in-system-design","status":"publish","type":"post","link":"https:\/\/www.guvi.in\/blog\/availability-in-system-design\/","title":{"rendered":"Availability in System Design: A Complete Beginner&#8217;s Guide"},"content":{"rendered":"\n<p>Think about the last time an app you use every day suddenly went down. Maybe it was a payment gateway right when you needed to check out, or a video streaming platform during a live event. That frustration you felt? It&#8217;s exactly what system designers are trying to prevent.<\/p>\n\n\n\n<p>Availability is one of the most fundamental concepts in system design. Whether you&#8217;re building a simple web app or a large-scale distributed system, understanding availability will shape nearly every architectural decision you make.<\/p>\n\n\n\n<p>In this article, you&#8217;ll learn what availability really means, how it&#8217;s measured, and, most importantly, what engineers actually do to keep systems running when things go wrong. If you have a basic understanding of programming and are just stepping into system design, this is the right place to start.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\"><strong>TL;DR Summary<\/strong><\/h2>\n\n\n\n<ol>\n<li>Availability in system design refers to the percentage of time a system remains operational and accessible to users, typically expressed using the concept of &#8220;nines&#8221; (99%, 99.9%, 99.99%, and so on).<\/li>\n\n\n\n<li>It is calculated using the formula: Availability (%) = Uptime \/ (Uptime + Downtime) \u00d7 100, and even a difference of one &#8220;nine&#8221; can mean hours versus minutes of annual downtime.<\/li>\n\n\n\n<li>Availability is closely related to but distinct from reliability \u2014 a system can be available but still return incorrect results, making both concepts essential to good system design.<\/li>\n\n\n\n<li>Key strategies to achieve high availability include redundancy, load balancing, failover mechanisms, replication, and health monitoring.<\/li>\n\n\n\n<li>The CAP theorem establishes that in distributed systems, you must always make a trade-off between availability and consistency during a network partition, understanding this is fundamental to designing real-world systems.<\/li>\n\n\n\n<li>This guide walks you through every core concept, from how availability is measured to the patterns engineers use to keep systems running around the clock.<\/li>\n<\/ol>\n\n\n\n<h2 class=\"wp-block-heading\"><strong>What is Availability in System Design?<\/strong><\/h2>\n\n\n\n<p>Availability in a <a href=\"https:\/\/www.guvi.in\/blog\/what-is-system-design\/\" target=\"_blank\" rel=\"noreferrer noopener\">system design<\/a> refers to the percentage of time a system is able to perform its task and function under normal conditions. Put simply, it answers one question: <em>Is the system up and accessible when a user needs it?<\/em><\/p>\n\n\n\n<p>But there&#8217;s a nuance worth noting early on. A system being &#8220;up&#8221; doesn&#8217;t necessarily mean it&#8217;s working correctly. It just means it can respond. That&#8217;s an important distinction you&#8217;ll revisit when comparing availability with reliability.<\/p>\n\n\n\n<p>Availability refers to the ability of a system to remain operational and accessible to users even in the face of various failures, disruptions, and maintenance activities. This is why it&#8217;s not just about keeping servers running, it&#8217;s about designing systems that can <em>absorb failures<\/em> gracefully and continue serving users without them even noticing.<a href=\"https:\/\/medium.com\/@vndee.huynh\/system-design-note-03-availability-dbbb78e7853a\" target=\"_blank\" rel=\"noopener\">&nbsp;<\/a><\/p>\n\n\n\n<h2 class=\"wp-block-heading\"><strong>How is Availability Measured?<\/strong><\/h2>\n\n\n\n<p>Availability is expressed as a percentage and calculated using a straightforward formula:<\/p>\n\n\n\n<p><strong>Availability (%) = (Uptime \/ (Uptime + Downtime)) \u00d7 100<\/strong><\/p>\n\n\n\n<p>For example, if a system has 99.9% availability in a year, the total time in a year is 525,600 minutes. That means the downtime allowed is just 0.1% \u00d7 525,600 = 525.6 minutes, roughly 8.76 hours.<a href=\"https:\/\/www.geeksforgeeks.org\/system-design\/availability-in-system-design\/\" target=\"_blank\" rel=\"noopener\">&nbsp;<\/a><\/p>\n\n\n\n<p>At first glance, 99.9% sounds excellent. But when you translate it into real time, that&#8217;s nearly nine hours of potential downtime per year. For a financial system or an e-commerce platform, that&#8217;s a very big deal.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\"><strong>Understanding the &#8220;Nines&#8221; of Availability<\/strong><\/h2>\n\n\n\n<p>Engineers don&#8217;t usually talk about availability as a raw percentage. Instead, they use a shorthand called &#8220;nines.&#8221;<\/p>\n\n\n\n<p>In the context of system availability, &#8220;nines&#8221; is a method of expressing uptime as a percentage by counting the decimal places of &#8220;9&#8221; in the figure. Each additional &#8220;9&#8221; represents a higher level of availability.<a href=\"https:\/\/signoz.io\/comparisons\/availability-vs-reliability\/\" target=\"_blank\" rel=\"noopener\">&nbsp;<\/a><\/p>\n\n\n\n<p>Here&#8217;s a quick breakdown of what each level actually means in practice:<\/p>\n\n\n\n<figure class=\"wp-block-table\"><table><tbody><tr><td><strong>Availability<\/strong><\/td><td><strong>Nines<\/strong><\/td><td><strong>Annual Downtime<\/strong><\/td><\/tr><tr><td>99%<\/td><td>Two nines<\/td><td>~3.65 days<\/td><\/tr><tr><td>99.9%<\/td><td>Three nines<\/td><td>~8.76 hours<\/td><\/tr><tr><td>99.99%<\/td><td>Four nines<\/td><td>~52.56 minutes<\/td><\/tr><tr><td>99.999%<\/td><td>Five nines<\/td><td>~5.26 minutes<\/td><\/tr><\/tbody><\/table><figcaption class=\"wp-element-caption\"><strong>Understanding the &#8220;Nines&#8221; of Availability<\/strong><\/figcaption><\/figure>\n\n\n\n<p>A system with 5 nines (99.999%) is considered the gold standard of availability. You&#8217;ll often see this target in critical infrastructure like air traffic control systems, banking platforms, and healthcare applications.<\/p>\n\n\n\n<p>The jump from four nines to five nines might seem small on paper, but engineering for that extra decimal point is extraordinarily complex and expensive. This is why not every system needs five nines, the target you choose should match the actual consequences of downtime for your users.<\/p>\n\n\n\n<div style=\"background-color: #099f4e; border: 3px solid #110053; border-radius: 12px; padding: 18px 22px; color: #FFFFFF; font-size: 18px; font-family: Montserrat, Helvetica, sans-serif; line-height: 1.6; box-shadow: 0 4px 12px rgba(0, 0, 0, 0.15); max-width: 750px;\">\n  <strong style=\"font-size: 22px; color: #FFFFFF;\">\ud83d\udca1 Did You Know?<\/strong>\n  <br \/><br \/>\n  Air traffic control systems are among the systems that require the highest availability because a single error in directing aeroplanes can lead to catastrophic results. High availability always comes with a cost, so systems need to optimize based on their actual needs. This is why engineers always start by asking: What is the cost of downtime for this specific system?\u00a0\n<\/div>\n\n\n\n<h2 class=\"wp-block-heading\"><strong>Why Availability Matters in System Design<\/strong><\/h2>\n\n\n\n<p>You might wonder why availability gets so much attention in system design discussions. Here are the core reasons:<\/p>\n\n\n\n<ul>\n<li><a href=\"https:\/\/www.guvi.in\/blog\/what-is-user-experience\/\" target=\"_blank\" rel=\"noreferrer noopener\"><strong>User Experience<\/strong><\/a><strong>:<\/strong> Users expect services to be accessible 24\/7. Frequent downtime erodes trust faster than almost anything else.<\/li>\n\n\n\n<li><strong>Business Continuity:<\/strong> High availability helps maintain continuous operations and prevents financial loss, reputational damage, and legal issues caused by system outages.<a href=\"https:\/\/www.geeksforgeeks.org\/system-design\/availability-in-system-design\/\" target=\"_blank\" rel=\"noopener\">&nbsp;<\/a><\/li>\n\n\n\n<li><strong>SLA Commitments:<\/strong> Organizations commit to specific uptime targets through Service Level Agreements (SLAs), and failure to meet them can lead to penalties or consequences.<a href=\"https:\/\/www.geeksforgeeks.org\/system-design\/availability-in-system-design\/\" target=\"_blank\" rel=\"noopener\">&nbsp;<\/a><\/li>\n\n\n\n<li><strong>Competitive Pressure:<\/strong> In markets like e-commerce or fintech, downtime directly translates to lost revenue and customers moving to competitors.<\/li>\n<\/ul>\n\n\n\n<p>SLIs (Service Level Indicators) are the measured metrics, SLOs (Service Level Objectives) are the target goals, and SLAs (Service Level Agreements) are the contracts with users regarding acceptable downtime. Understanding these three terms helps you see how availability commitments flow from engineering decisions all the way to business agreements.<a href=\"https:\/\/www.systemdesignhandbook.com\/guides\/system-design\/\" target=\"_blank\" rel=\"noopener\">&nbsp;<\/a><\/p>\n\n\n\n<h2 class=\"wp-block-heading\"><strong>Key Strategies to Achieve High Availability<\/strong><\/h2>\n\n\n\n<p>Now here&#8217;s where things get practical. Knowing what availability is matters less than knowing how to actually achieve it. Let&#8217;s walk through the core strategies engineers use.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\"><strong>Redundancy<\/strong><\/h3>\n\n\n\n<p>Redundancy is a fundamental concept in system design to ensure availability. It involves having backup components or systems in place to take over in case of failure, applied to servers, databases, network connections, or power supplies.<a href=\"https:\/\/medium.com\/@vndee.huynh\/system-design-note-03-availability-dbbb78e7853a\" target=\"_blank\" rel=\"noopener\">&nbsp;<\/a><\/p>\n\n\n\n<p>There are two types of redundancy you should know:<\/p>\n\n\n\n<ul>\n<li><strong>Passive Redundancy:<\/strong> Only some components are active at any given time. Backup components are available in case of a failure. If one component fails, the backup will take over and become active.<\/li>\n\n\n\n<li><strong>Active Redundancy:<\/strong> Multiple active components work simultaneously. In the event of a failure of one, the other active components take over.<\/li>\n<\/ul>\n\n\n\n<p>Active redundancy provides faster recovery because there&#8217;s no &#8220;cold start&#8221; delay, but it also costs more to run. Which one you choose depends on your availability targets and budget.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\"><strong>Load Balancing<\/strong><\/h3>\n\n\n\n<p>Load balancers are the traffic directors of a system. They continually monitor the health of service instances and distribute incoming requests among them. If a service instance becomes unhealthy or unresponsive, the load balancer can automatically divert traffic to healthy instances, ensuring that users experience minimal disruption and downtime.<a href=\"https:\/\/medium.com\/@vndee.huynh\/system-design-note-03-availability-dbbb78e7853a\" target=\"_blank\" rel=\"noopener\">&nbsp;<\/a><\/p>\n\n\n\n<p>Think of a load balancer as the host at a busy restaurant, directing guests to available tables so no single waiter is overwhelmed while others stand idle.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\"><strong>Failover Mechanisms<\/strong><\/h3>\n\n\n\n<p>Failover is what happens when a primary component fails and the system automatically switches to a backup. Good failover design is what separates a system with occasional hiccups from one that users never notice going down.<\/p>\n\n\n\n<p>Services should be designed to handle failover gracefully. Load balancers often play a crucial role in this: if a service instance becomes unhealthy, the load balancer can automatically divert traffic to healthy instances.<a href=\"https:\/\/medium.com\/@vndee.huynh\/system-design-note-03-availability-dbbb78e7853a\" target=\"_blank\" rel=\"noopener\">&nbsp;<\/a><\/p>\n\n\n\n<p>The keyword here is <em>automatically<\/em>. Manual failover, where someone has to notice the problem and intervene, takes too long for systems targeting high availability.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\"><strong>Replication<\/strong><\/h3>\n\n\n\n<p>Replication means keeping copies of your data across multiple nodes or locations. Replication works alongside redundancy by keeping duplicate components synchronised. It ensures that data or system state remains consistent across redundant resources.<a href=\"https:\/\/dev.to\/fahimulhaq\/complete-guide-to-system-design-oc7\" target=\"_blank\" rel=\"noopener\">&nbsp;<\/a><\/p>\n\n\n\n<p>Replication can also be extended across geographic regions to reduce latency and maintain availability during regional outages. This is why major platforms like Netflix and Google serve users from data centers closest to them, if one region goes down, another picks up the load.<a href=\"https:\/\/dev.to\/fahimulhaq\/complete-guide-to-system-design-oc7\" target=\"_blank\" rel=\"noopener\">&nbsp;<\/a><\/p>\n\n\n\n<h3 class=\"wp-block-heading\"><strong>Health Monitoring and Proactive Alerts<\/strong><\/h3>\n\n\n\n<p>Proactive monitoring is crucial for identifying and resolving issues before they escalate and impact system availability. Monitoring tools and techniques can help system administrators detect anomalies, identify performance bottlenecks, and take necessary actions to prevent potential failures.<a href=\"https:\/\/www.designgurus.io\/blog\/high-availability-system-design-basics\" target=\"_blank\" rel=\"noopener\">&nbsp;<\/a><\/p>\n\n\n\n<p>Reactive systems wait for things to break. Proactive systems catch warning signs before they become outages. Building in health checks, alerting pipelines, and automated recovery scripts is a core part of high-availability architecture.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\"><strong>Availability and the CAP Theorem<\/strong><\/h2>\n\n\n\n<p>Once you start building distributed systems, you&#8217;ll inevitably encounter the <a href=\"https:\/\/www.ibm.com\/think\/topics\/cap-theorem\" target=\"_blank\" rel=\"noreferrer noopener nofollow\">CAP theorem<\/a>. It&#8217;s one of the most important ideas in system design, and it directly shapes how you think about availability.<\/p>\n\n\n\n<p>The CAP theorem, introduced by Eric Brewer in 2000, states that it is impossible for a distributed data store to simultaneously provide all three guarantees: Consistency (every read receives the most recent write or an error), Availability (every request receives a non-error response, without guarantee that it contains the most recent write), and Partition Tolerance (the system continues to operate despite network failures between nodes).<a href=\"https:\/\/blog.algomaster.io\/p\/cap-theorem-explained\" target=\"_blank\" rel=\"noopener\">&nbsp;<\/a><\/p>\n\n\n\n<p>In the theorem, partition tolerance is a must. Network failures will happen, so to offer any kind of reliable service, partition tolerance is necessary. That leaves a decision between Consistency and Availability.<a href=\"https:\/\/www.bmc.com\/blogs\/cap-theorem\/\" target=\"_blank\" rel=\"noopener\">&nbsp;<\/a><\/p>\n\n\n\n<p>In plain terms: when your network has a problem, you have to choose. Do you want every user to get a response, even if that response might be slightly outdated (availability)? Or do you want the system to hold off responding until it&#8217;s certain the data is accurate (consistency)?<\/p>\n\n\n\n<p>Different systems make different choices:<\/p>\n\n\n\n<ul>\n<li><strong>E-commerce shopping carts<\/strong> often favour availability, better to show a slightly stale cart than to show an error page.<\/li>\n\n\n\n<li><strong>Banking systems<\/strong> often favour consistency, better to briefly reject a request than to process a transaction on incorrect data.<\/li>\n<\/ul>\n\n\n\n<p>Understanding this trade-off is essential when you&#8217;re deciding on databases and architecture for real-world systems.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\"><strong>Real-World Examples of Availability in Action<\/strong><\/h2>\n\n\n\n<p>It helps to see how availability plays out in systems you already use every day.<\/p>\n\n\n\n<p><strong>Cloud Platforms (AWS, GCP, Azure):<\/strong> These platforms deploy services across multiple availability zones, physically separated data centres within the same region. If one zone goes down due to a power failure or network issue, traffic automatically shifts to another zone. Users experience nothing.<\/p>\n\n\n\n<p><strong>Video Streaming (Netflix, YouTube):<\/strong> YouTube continues to operate after a data center failure due to its reliability at scale. Netflix uses a combination of horizontal scaling across multiple geographical regions plus intelligent caching to serve millions of simultaneous streams every day, all while maintaining high availability.<\/p>\n\n\n\n<p><strong>E-commerce (Amazon):<\/strong> During peak events like Black Friday, Amazon&#8217;s systems handle enormous traffic spikes. Their architecture is specifically designed to prioritise availability during these windows, even accepting the occasional slight data inconsistency in non-critical areas, so that users can always browse and purchase.<\/p>\n\n\n\n<p><strong>Payment Gateways:<\/strong> These systems aim for extremely high availability (often targeting four or five nines) because any downtime translates directly to failed transactions and immediate revenue loss. They use active redundancy, geographic replication, and aggressive health monitoring to achieve this.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\"><strong>Common Trade-offs You Should Know About<\/strong><\/h2>\n\n\n\n<p>High availability is never free. Every design decision that increases availability introduces some cost or complexity. Here are the most common trade-offs to keep in mind:<\/p>\n\n\n\n<ul>\n<li><strong>Cost vs. Availability:<\/strong> More redundancy means more infrastructure. Running duplicate servers, replicating data across regions, and maintaining failover systems all cost money. This is why you calibrate your availability target to what your system actually needs.<\/li>\n\n\n\n<li><strong>Consistency vs. Availability:<\/strong> As covered in the CAP theorem section, prioritising availability often means accepting that some responses might carry slightly stale data. This is a fundamental trade-off in distributed systems.<\/li>\n\n\n\n<li><strong>Complexity vs. Maintainability:<\/strong> Highly scalable architectures with distributed nodes across regions can isolate failures and improve availability, but they also introduce more points of failure. More components mean more things that can go wrong and more expertise needed to manage them.<a href=\"https:\/\/designgurus.substack.com\/p\/scalability-vs-reliability-vs-availability\" target=\"_blank\" rel=\"noopener\">&nbsp;<\/a><\/li>\n\n\n\n<li><strong>Performance vs. Availability:<\/strong> Some availability techniques, like synchronous replication, can add latency. Engineers have to find the right balance between speed and resilience.<\/li>\n<\/ul>\n\n\n\n<p>These trade-offs don&#8217;t have universal right answers. They depend entirely on your system&#8217;s purpose, your users&#8217; expectations, and the real cost of downtime for your specific context.<\/p>\n\n\n\n<p>If you\u2019re serious about mastering scalability in system design and software development and want to apply it in real-world scenarios, don\u2019t miss the chance to enroll in HCL GUVI\u2019s IITM Pravartak and MongoDB Certified Online <a href=\"https:\/\/www.guvi.in\/zen-class\/ai-software-development-course\/?utm_source=blog&amp;utm_medium=hyperlink&amp;utm_campaign=availability-in-system-design\" target=\"_blank\" rel=\"noreferrer noopener\">AI Software Development Course<\/a>. Endorsed with NSDC certification, this course adds a globally recognized credential to your resume, a powerful edge that sets you apart in the competitive job market.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\"><strong>Conclusion<\/strong><\/h2>\n\n\n\n<p>In conclusion, availability is one of the cornerstones of good system design. Once you understand it, you start seeing it everywhere, in how databases replicate data, how load balancers route traffic, how cloud providers structure their infrastructure, and how businesses draft their SLAs.<\/p>\n\n\n\n<p>The core idea is simple: build systems that keep working even when individual components fail. The execution, however, involves careful decisions around redundancy, replication, failover, monitoring, and trade-offs like the CAP theorem.<\/p>\n\n\n\n<p>As you continue learning system design, availability will keep showing up alongside scalability, reliability, and consistency. Each concept builds on the others. Start with availability, understand it deeply, and the rest of system design will begin to click into place.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\"><strong>FAQs<\/strong><\/h2>\n\n\n<div id=\"rank-math-faq\" class=\"rank-math-block\">\n<div class=\"rank-math-list \">\n<div id=\"faq-question-1778732607920\" class=\"rank-math-list-item\">\n<h3 class=\"rank-math-question \"><strong>What is availability in system design?<\/strong>\u00a0<\/h3>\n<div class=\"rank-math-answer \">\n\n<p>Availability in system design is the percentage of time a system remains operational and accessible to users. It measures how well a system continues to function despite failures, and is typically expressed using &#8220;nines&#8221; (e.g., 99.9% or 99.99% uptime).<\/p>\n\n<\/div>\n<\/div>\n<div id=\"faq-question-1778732610996\" class=\"rank-math-list-item\">\n<h3 class=\"rank-math-question \"><strong>How is availability calculated?<\/strong>\u00a0<\/h3>\n<div class=\"rank-math-answer \">\n\n<p>Availability is calculated using the formula: Availability (%) = (Uptime \/ (Uptime + Downtime)) \u00d7 100. The result is expressed as a percentage and often described in &#8220;nines&#8221; notation.<\/p>\n\n<\/div>\n<\/div>\n<div id=\"faq-question-1778732615582\" class=\"rank-math-list-item\">\n<h3 class=\"rank-math-question \"><strong>What does &#8220;five nines&#8221; availability mean?<\/strong>\u00a0<\/h3>\n<div class=\"rank-math-answer \">\n\n<p>Five nines refers to 99.999% uptime. It allows for only around 5.26 minutes of downtime per year and is considered the gold standard for highly critical systems.<\/p>\n\n<\/div>\n<\/div>\n<div id=\"faq-question-1778732621866\" class=\"rank-math-list-item\">\n<h3 class=\"rank-math-question \"><strong>What is the difference between availability and reliability?<\/strong>\u00a0<\/h3>\n<div class=\"rank-math-answer \">\n\n<p>Availability is about whether a system is up and responding. Reliability is about whether it&#8217;s responding correctly and consistently. A system can be available (responding) but unreliable (returning wrong results).<\/p>\n\n<\/div>\n<\/div>\n<div id=\"faq-question-1778732626315\" class=\"rank-math-list-item\">\n<h3 class=\"rank-math-question \"><strong>What is the CAP theorem and how does it relate to availability?<\/strong>\u00a0<\/h3>\n<div class=\"rank-math-answer \">\n\n<p>The CAP theorem states that a distributed system can only guarantee two of three properties at once: Consistency, Availability, and Partition Tolerance. Since partition tolerance is always required in distributed systems, engineers must choose between consistency and availability during a network failure.<\/p>\n\n<\/div>\n<\/div>\n<\/div>\n<\/div>","protected":false},"excerpt":{"rendered":"<p>Think about the last time an app you use every day suddenly went down. Maybe it was a payment gateway right when you needed to check out, or a video streaming platform during a live event. That frustration you felt? It&#8217;s exactly what system designers are trying to prevent. Availability is one of the most [&hellip;]<\/p>\n","protected":false},"author":22,"featured_media":110890,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[959],"tags":[],"views":"36","authorinfo":{"name":"Lukesh S","url":"https:\/\/www.guvi.in\/blog\/author\/lukesh\/"},"thumbnailURL":"https:\/\/www.guvi.in\/blog\/wp-content\/uploads\/2026\/05\/Availability-300x115.webp","jetpack_featured_media_url":"https:\/\/www.guvi.in\/blog\/wp-content\/uploads\/2026\/05\/Availability-scaled.webp","_links":{"self":[{"href":"https:\/\/www.guvi.in\/blog\/wp-json\/wp\/v2\/posts\/110821"}],"collection":[{"href":"https:\/\/www.guvi.in\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.guvi.in\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.guvi.in\/blog\/wp-json\/wp\/v2\/users\/22"}],"replies":[{"embeddable":true,"href":"https:\/\/www.guvi.in\/blog\/wp-json\/wp\/v2\/comments?post=110821"}],"version-history":[{"count":4,"href":"https:\/\/www.guvi.in\/blog\/wp-json\/wp\/v2\/posts\/110821\/revisions"}],"predecessor-version":[{"id":110891,"href":"https:\/\/www.guvi.in\/blog\/wp-json\/wp\/v2\/posts\/110821\/revisions\/110891"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.guvi.in\/blog\/wp-json\/wp\/v2\/media\/110890"}],"wp:attachment":[{"href":"https:\/\/www.guvi.in\/blog\/wp-json\/wp\/v2\/media?parent=110821"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.guvi.in\/blog\/wp-json\/wp\/v2\/categories?post=110821"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.guvi.in\/blog\/wp-json\/wp\/v2\/tags?post=110821"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}