{"id":68,"date":"2014-06-15T12:21:42","date_gmt":"2014-06-15T06:51:42","guid":{"rendered":"https:\/\/unwiredlabs.com\/blog\/?p=68"},"modified":"2014-09-06T11:28:56","modified_gmt":"2014-09-06T05:58:56","slug":"getting-to-100-percent-uptime","status":"publish","type":"post","link":"https:\/\/unwiredlabs.com\/blog\/getting-to-100-percent-uptime\/","title":{"rendered":"Getting to 100% uptime"},"content":{"rendered":"

As a startup, adding high-availability can be both time consuming and expensive; two factors usually more critical than high-availability itself. Like most startups, we bootstrapped on AWS<\/a>\u00a0with an app server, a DB server, no replication or backups and a few Cloud Watch alarms.<\/p>\n

\"aws_high_availability_in_cloud\"<\/a><\/p>\n

As luck would have it, we had no major down-times and this\u00a0scaled easily to our first 100 users. Even at this scale, we couldn’t sleep too well at night, knowing that a down-time would affect a lot of critical services relying on our API. One day, we decided enough was enough and set out to build a good, solid infrastructure.\u00a0Our team put in place a cost-effective (opinions welcome here!) solution that comprises multiple solutions, some of which can take minutes to configure, and others days.<\/p>\n

Here’s an extremely brief overview of what we did:<\/span><\/p>\n

    \n
  1. Monitoring<\/strong>
    \nWe setup a server outside our main infrastructure provider that runs     Nagios \/ Icinga<\/a>. It monitors all services (API health, CPU, RAM, etc) on all hosts. It also calls us<\/a> if there’s something critically wrong with any service, so we know about it right away.<\/li>\n
  2. Load balancers, and many many more instances<\/strong>
    \nTo scale requests on our primary endpoint, we added more App servers, replication and daily back-ups in different physical locations \/ data-centers, and put them behind load balancers. For our servers on AWS, we used their load-balancer. For others, we deployed a reverse-proxy using HAProxy to achieve this.<\/li>\n
  3. Multiple end-points<\/strong>
    \nOur API serves customers world-wide, and it made sense to launch similar infrastructure in multiple locations. All it took was rock-solid replication (with alerts if it fails), fast     DNS servers<\/a>\u00a0and a little more money. We were also careful to pick different data-centers for each location, to decrease risk of downtime due to hardware failures. This was a win-win for customers because it reduced latency for them and us, because the load on the primary endpoint was lesser.<\/li>\n
  4. DNS-based Failovers<\/strong>
    \nAnother win for a multiple end-point architecture is the ability to reroute requests from one \u00a0endpoint to another, in the event of down-time, with just a DNS change. With     Cloudflare<\/a> as our DNS provider, and per second health-checks by CloudRoutes<\/a>, we could reroute requests instantly (again, via CloudRoutes), and with zero down-time. DNS time-to-live doesn’t matter because our servers are behind Cloudflare’s reverse proxy; it’s our IP that changes, not theirs.<\/li>\n
  5. Keeping track of logs<\/strong>
    \nThere were so many things happening in our systems – malicious requests, slow requests, buggy code – that weren’t very visible. Then we found a     great logging solution<\/a>. All system and API log files are shipped to this logger, email and web-hook alerts are created based on simple searches.<\/li>\n
  6. Processes<\/strong>
    \nWe can’t stress enough on this one! From having someone responsible for code-review before pushing it to production, to drawing straws on who would get the first phone call if there was a problem after hours, we spent sometime putting     SOPs<\/a> down on paper and on an internal wiki<\/a>.<\/li>\n<\/ol>\n

    The industry standard seems to be 99.95%, but when thousands rely on our platform for non-trivial use cases, we think 100% availability is pretty darn important.<\/p>\n","protected":false},"excerpt":{"rendered":"

    As a startup, adding high-availability can be both time consuming and expensive; two factors usually more critical than high-availability itself. Like most startups, we bootstrapped on AWS\u00a0with an app server, a DB server, no replication or backups and a few Cloud Watch alarms. As luck would have it, we had no major down-times and this\u00a0scaled easily to our first 100 users. Even at this scale, we couldn’t sleep too well at night, knowing that a down-time would affect a lot of critical services relying on our API. One day, we decided enough was enough and set out to build a good, solid infrastructure.\u00a0Our team put in place a cost-effective (opinions welcome here!) solution that comprises multiple solutions, some of which can take minutes to configure, and others days. Here’s an extremely brief overview of what we did: Monitoring We setup a server outside our main infrastructure provider that runs Nagios \/ Icinga. It monitors all services (API health, CPU, RAM, etc) on all hosts. It also calls us if there’s something critically wrong with any service, so we know about it right away. Load balancers, and many many more instances To scale requests on our primary endpoint, we added more App servers, replication and daily back-ups in different physical locations \/ data-centers, and put them behind load balancers. For our servers on AWS, we used their load-balancer. For others, we deployed a reverse-proxy using HAProxy to achieve this. Multiple end-points Our API serves customers world-wide, and it made sense to launch similar infrastructure in multiple locations. All it took was rock-solid replication (with alerts if it fails), fast DNS servers\u00a0and a little more money. We were also careful to pick different data-centers for each location, to decrease risk of downtime due to hardware failures. This was a win-win for customers because it reduced latency for them and us, because the load on the primary endpoint was lesser. DNS-based Failovers Another win for a multiple end-point architecture is the ability to reroute requests from one \u00a0endpoint to another, in the event of down-time, with just a DNS change. With Cloudflare as our DNS provider, and per second health-checks by CloudRoutes, we could reroute requests instantly (again, via CloudRoutes), and with zero down-time. DNS time-to-live doesn’t matter because our servers are behind Cloudflare’s reverse proxy; it’s our IP that changes, not theirs. Keeping track of logs There were so many things happening in our systems – malicious requests, slow requests, buggy code – that weren’t very visible. Then we found a great logging solution. All system and API log files are shipped to this logger, email and web-hook alerts are created based on simple searches. Processes We can’t stress enough on this one! From having someone responsible for code-review before pushing it to production, to drawing straws on who would get the first phone call if there was a problem after hours, we spent sometime putting SOPs down on paper and on an internal wiki. The industry standard seems to be 99.95%, but when thousands rely on our platform for non-trivial use cases, we think 100% availability is pretty darn important.<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[7],"tags":[],"class_list":["post-68","post","type-post","status-publish","format-standard","hentry","category-engineering"],"yoast_head":"\nHigh availability for tech startup - 100% uptime<\/title>\n<meta name=\"robots\" content=\"index, follow, max-snippet:-1, max-image-preview:large, max-video-preview:-1\" \/>\n<link rel=\"canonical\" href=\"https:\/\/unwiredlabs.com\/blog\/getting-to-100-percent-uptime\/\" \/>\n<meta property=\"og:locale\" content=\"en_US\" \/>\n<meta property=\"og:type\" content=\"article\" \/>\n<meta property=\"og:title\" content=\"High availability for tech startup - 100% uptime\" \/>\n<meta property=\"og:description\" content=\"As a startup, adding high-availability can be both time consuming and expensive; two factors usually more critical than high-availability itself. Like most startups, we bootstrapped on AWS\u00a0with an app server, a DB server, no replication or backups and a few Cloud Watch alarms. As luck would have it, we had no major down-times and this\u00a0scaled easily to our first 100 users. Even at this scale, we couldn’t sleep too well at night, knowing that a down-time would affect a lot of critical services relying on our API. One day, we decided enough was enough and set out to build a good, solid infrastructure.\u00a0Our team put in place a cost-effective (opinions welcome here!) solution that comprises multiple solutions, some of which can take minutes to configure, and others days. Here’s an extremely brief overview of what we did: Monitoring We setup a server outside our main infrastructure provider that runs Nagios \/ Icinga. It monitors all services (API health, CPU, RAM, etc) on all hosts. It also calls us if there’s something critically wrong with any service, so we know about it right away. Load balancers, and many many more instances To scale requests on our primary endpoint, we added more App servers, replication and daily back-ups in different physical locations \/ data-centers, and put them behind load balancers. For our servers on AWS, we used their load-balancer. For others, we deployed a reverse-proxy using HAProxy to achieve this. Multiple end-points Our API serves customers world-wide, and it made sense to launch similar infrastructure in multiple locations. All it took was rock-solid replication (with alerts if it fails), fast DNS servers\u00a0and a little more money. We were also careful to pick different data-centers for each location, to decrease risk of downtime due to hardware failures. This was a win-win for customers because it reduced latency for them and us, because the load on the primary endpoint was lesser. DNS-based Failovers Another win for a multiple end-point architecture is the ability to reroute requests from one \u00a0endpoint to another, in the event of down-time, with just a DNS change. With Cloudflare as our DNS provider, and per second health-checks by CloudRoutes, we could reroute requests instantly (again, via CloudRoutes), and with zero down-time. DNS time-to-live doesn’t matter because our servers are behind Cloudflare’s reverse proxy; it’s our IP that changes, not theirs. Keeping track of logs There were so many things happening in our systems – malicious requests, slow requests, buggy code – that weren’t very visible. Then we found a great logging solution. All system and API log files are shipped to this logger, email and web-hook alerts are created based on simple searches. Processes We can’t stress enough on this one! From having someone responsible for code-review before pushing it to production, to drawing straws on who would get the first phone call if there was a problem after hours, we spent sometime putting SOPs down on paper and on an internal wiki. The industry standard seems to be 99.95%, but when thousands rely on our platform for non-trivial use cases, we think 100% availability is pretty darn important.\" \/>\n<meta property=\"og:url\" content=\"https:\/\/unwiredlabs.com\/blog\/getting-to-100-percent-uptime\/\" \/>\n<meta property=\"og:site_name\" content=\"The Unwired Labs Blog\" \/>\n<meta property=\"article:published_time\" content=\"2014-06-15T06:51:42+00:00\" \/>\n<meta property=\"article:modified_time\" content=\"2014-09-06T05:58:56+00:00\" \/>\n<meta property=\"og:image\" content=\"https:\/\/unwiredlabs.com\/blog\/wp-content\/uploads\/2014\/07\/aws_high_availability_in_cloud.jpg\" \/>\n<meta name=\"author\" content=\"Aravind\" \/>\n<meta name=\"twitter:label1\" content=\"Written by\" \/>\n\t<meta name=\"twitter:data1\" content=\"Aravind\" \/>\n\t<meta name=\"twitter:label2\" content=\"Est. reading time\" \/>\n\t<meta name=\"twitter:data2\" content=\"3 minutes\" \/>\n<script type=\"application\/ld+json\" class=\"yoast-schema-graph\">{\"@context\":\"https:\/\/schema.org\",\"@graph\":[{\"@type\":\"Article\",\"@id\":\"https:\/\/unwiredlabs.com\/blog\/getting-to-100-percent-uptime\/#article\",\"isPartOf\":{\"@id\":\"https:\/\/unwiredlabs.com\/blog\/getting-to-100-percent-uptime\/\"},\"author\":{\"name\":\"Aravind\",\"@id\":\"https:\/\/unwiredlabs.com\/blog\/#\/schema\/person\/7340c085bb8b318dd3e8f44272ff67db\"},\"headline\":\"Getting to 100% uptime\",\"datePublished\":\"2014-06-15T06:51:42+00:00\",\"dateModified\":\"2014-09-06T05:58:56+00:00\",\"mainEntityOfPage\":{\"@id\":\"https:\/\/unwiredlabs.com\/blog\/getting-to-100-percent-uptime\/\"},\"wordCount\":529,\"commentCount\":0,\"publisher\":{\"@id\":\"https:\/\/unwiredlabs.com\/blog\/#organization\"},\"image\":{\"@id\":\"https:\/\/unwiredlabs.com\/blog\/getting-to-100-percent-uptime\/#primaryimage\"},\"thumbnailUrl\":\"https:\/\/unwiredlabs.com\/blog\/wp-content\/uploads\/2014\/07\/aws_high_availability_in_cloud.jpg\",\"articleSection\":[\"Engineering\"],\"inLanguage\":\"en-US\",\"potentialAction\":[{\"@type\":\"CommentAction\",\"name\":\"Comment\",\"target\":[\"https:\/\/unwiredlabs.com\/blog\/getting-to-100-percent-uptime\/#respond\"]}]},{\"@type\":\"WebPage\",\"@id\":\"https:\/\/unwiredlabs.com\/blog\/getting-to-100-percent-uptime\/\",\"url\":\"https:\/\/unwiredlabs.com\/blog\/getting-to-100-percent-uptime\/\",\"name\":\"High availability for tech startup - 100% uptime\",\"isPartOf\":{\"@id\":\"https:\/\/unwiredlabs.com\/blog\/#website\"},\"primaryImageOfPage\":{\"@id\":\"https:\/\/unwiredlabs.com\/blog\/getting-to-100-percent-uptime\/#primaryimage\"},\"image\":{\"@id\":\"https:\/\/unwiredlabs.com\/blog\/getting-to-100-percent-uptime\/#primaryimage\"},\"thumbnailUrl\":\"https:\/\/unwiredlabs.com\/blog\/wp-content\/uploads\/2014\/07\/aws_high_availability_in_cloud.jpg\",\"datePublished\":\"2014-06-15T06:51:42+00:00\",\"dateModified\":\"2014-09-06T05:58:56+00:00\",\"breadcrumb\":{\"@id\":\"https:\/\/unwiredlabs.com\/blog\/getting-to-100-percent-uptime\/#breadcrumb\"},\"inLanguage\":\"en-US\",\"potentialAction\":[{\"@type\":\"ReadAction\",\"target\":[\"https:\/\/unwiredlabs.com\/blog\/getting-to-100-percent-uptime\/\"]}]},{\"@type\":\"ImageObject\",\"inLanguage\":\"en-US\",\"@id\":\"https:\/\/unwiredlabs.com\/blog\/getting-to-100-percent-uptime\/#primaryimage\",\"url\":\"https:\/\/unwiredlabs.com\/blog\/wp-content\/uploads\/2014\/07\/aws_high_availability_in_cloud.jpg\",\"contentUrl\":\"https:\/\/unwiredlabs.com\/blog\/wp-content\/uploads\/2014\/07\/aws_high_availability_in_cloud.jpg\",\"width\":400,\"height\":300},{\"@type\":\"BreadcrumbList\",\"@id\":\"https:\/\/unwiredlabs.com\/blog\/getting-to-100-percent-uptime\/#breadcrumb\",\"itemListElement\":[{\"@type\":\"ListItem\",\"position\":1,\"name\":\"Home\",\"item\":\"https:\/\/unwiredlabs.com\/blog\/\"},{\"@type\":\"ListItem\",\"position\":2,\"name\":\"Getting to 100% uptime\"}]},{\"@type\":\"WebSite\",\"@id\":\"https:\/\/unwiredlabs.com\/blog\/#website\",\"url\":\"https:\/\/unwiredlabs.com\/blog\/\",\"name\":\"The Unwired Labs Blog\",\"description\":\"\",\"publisher\":{\"@id\":\"https:\/\/unwiredlabs.com\/blog\/#organization\"},\"potentialAction\":[{\"@type\":\"SearchAction\",\"target\":{\"@type\":\"EntryPoint\",\"urlTemplate\":\"https:\/\/unwiredlabs.com\/blog\/?s={search_term_string}\"},\"query-input\":{\"@type\":\"PropertyValueSpecification\",\"valueRequired\":true,\"valueName\":\"search_term_string\"}}],\"inLanguage\":\"en-US\"},{\"@type\":\"Organization\",\"@id\":\"https:\/\/unwiredlabs.com\/blog\/#organization\",\"name\":\"The Unwired Labs Blog\",\"url\":\"https:\/\/unwiredlabs.com\/blog\/\",\"logo\":{\"@type\":\"ImageObject\",\"inLanguage\":\"en-US\",\"@id\":\"https:\/\/unwiredlabs.com\/blog\/#\/schema\/logo\/image\/\",\"url\":\"https:\/\/unwiredlabs.com\/blog\/wp-content\/uploads\/2025\/08\/cropped-Unwired-labs-logo-rectangle.png\",\"contentUrl\":\"https:\/\/unwiredlabs.com\/blog\/wp-content\/uploads\/2025\/08\/cropped-Unwired-labs-logo-rectangle.png\",\"width\":400,\"height\":200,\"caption\":\"The Unwired Labs Blog\"},\"image\":{\"@id\":\"https:\/\/unwiredlabs.com\/blog\/#\/schema\/logo\/image\/\"}},{\"@type\":\"Person\",\"@id\":\"https:\/\/unwiredlabs.com\/blog\/#\/schema\/person\/7340c085bb8b318dd3e8f44272ff67db\",\"name\":\"Aravind\",\"image\":{\"@type\":\"ImageObject\",\"inLanguage\":\"en-US\",\"@id\":\"https:\/\/unwiredlabs.com\/blog\/#\/schema\/person\/image\/\",\"url\":\"https:\/\/secure.gravatar.com\/avatar\/3b5f84db6919959ece5096fd6e5cdf8b23a6a514bd5405a9def531548ad9985b?s=96&d=blank&r=g\",\"contentUrl\":\"https:\/\/secure.gravatar.com\/avatar\/3b5f84db6919959ece5096fd6e5cdf8b23a6a514bd5405a9def531548ad9985b?s=96&d=blank&r=g\",\"caption\":\"Aravind\"},\"sameAs\":[\"https:\/\/x.com\/findinggopi\"],\"url\":\"https:\/\/unwiredlabs.com\/blog\/author\/admin\/\"}]}<\/script>\n<!-- \/ Yoast SEO plugin. -->","yoast_head_json":{"title":"High availability for tech startup - 100% uptime","robots":{"index":"index","follow":"follow","max-snippet":"max-snippet:-1","max-image-preview":"max-image-preview:large","max-video-preview":"max-video-preview:-1"},"canonical":"https:\/\/unwiredlabs.com\/blog\/getting-to-100-percent-uptime\/","og_locale":"en_US","og_type":"article","og_title":"High availability for tech startup - 100% uptime","og_description":"As a startup, adding high-availability can be both time consuming and expensive; two factors usually more critical than high-availability itself. Like most startups, we bootstrapped on AWS\u00a0with an app server, a DB server, no replication or backups and a few Cloud Watch alarms. As luck would have it, we had no major down-times and this\u00a0scaled easily to our first 100 users. Even at this scale, we couldn’t sleep too well at night, knowing that a down-time would affect a lot of critical services relying on our API. One day, we decided enough was enough and set out to build a good, solid infrastructure.\u00a0Our team put in place a cost-effective (opinions welcome here!) solution that comprises multiple solutions, some of which can take minutes to configure, and others days. Here’s an extremely brief overview of what we did: Monitoring We setup a server outside our main infrastructure provider that runs Nagios \/ Icinga. It monitors all services (API health, CPU, RAM, etc) on all hosts. It also calls us if there’s something critically wrong with any service, so we know about it right away. Load balancers, and many many more instances To scale requests on our primary endpoint, we added more App servers, replication and daily back-ups in different physical locations \/ data-centers, and put them behind load balancers. For our servers on AWS, we used their load-balancer. For others, we deployed a reverse-proxy using HAProxy to achieve this. Multiple end-points Our API serves customers world-wide, and it made sense to launch similar infrastructure in multiple locations. All it took was rock-solid replication (with alerts if it fails), fast DNS servers\u00a0and a little more money. We were also careful to pick different data-centers for each location, to decrease risk of downtime due to hardware failures. This was a win-win for customers because it reduced latency for them and us, because the load on the primary endpoint was lesser. DNS-based Failovers Another win for a multiple end-point architecture is the ability to reroute requests from one \u00a0endpoint to another, in the event of down-time, with just a DNS change. With Cloudflare as our DNS provider, and per second health-checks by CloudRoutes, we could reroute requests instantly (again, via CloudRoutes), and with zero down-time. DNS time-to-live doesn’t matter because our servers are behind Cloudflare’s reverse proxy; it’s our IP that changes, not theirs. Keeping track of logs There were so many things happening in our systems – malicious requests, slow requests, buggy code – that weren’t very visible. Then we found a great logging solution. All system and API log files are shipped to this logger, email and web-hook alerts are created based on simple searches. Processes We can’t stress enough on this one! From having someone responsible for code-review before pushing it to production, to drawing straws on who would get the first phone call if there was a problem after hours, we spent sometime putting SOPs down on paper and on an internal wiki. The industry standard seems to be 99.95%, but when thousands rely on our platform for non-trivial use cases, we think 100% availability is pretty darn important.","og_url":"https:\/\/unwiredlabs.com\/blog\/getting-to-100-percent-uptime\/","og_site_name":"The Unwired Labs Blog","article_published_time":"2014-06-15T06:51:42+00:00","article_modified_time":"2014-09-06T05:58:56+00:00","og_image":[{"url":"https:\/\/unwiredlabs.com\/blog\/wp-content\/uploads\/2014\/07\/aws_high_availability_in_cloud.jpg","type":"","width":"","height":""}],"author":"Aravind","twitter_misc":{"Written by":"Aravind","Est. reading time":"3 minutes"},"schema":{"@context":"https:\/\/schema.org","@graph":[{"@type":"Article","@id":"https:\/\/unwiredlabs.com\/blog\/getting-to-100-percent-uptime\/#article","isPartOf":{"@id":"https:\/\/unwiredlabs.com\/blog\/getting-to-100-percent-uptime\/"},"author":{"name":"Aravind","@id":"https:\/\/unwiredlabs.com\/blog\/#\/schema\/person\/7340c085bb8b318dd3e8f44272ff67db"},"headline":"Getting to 100% uptime","datePublished":"2014-06-15T06:51:42+00:00","dateModified":"2014-09-06T05:58:56+00:00","mainEntityOfPage":{"@id":"https:\/\/unwiredlabs.com\/blog\/getting-to-100-percent-uptime\/"},"wordCount":529,"commentCount":0,"publisher":{"@id":"https:\/\/unwiredlabs.com\/blog\/#organization"},"image":{"@id":"https:\/\/unwiredlabs.com\/blog\/getting-to-100-percent-uptime\/#primaryimage"},"thumbnailUrl":"https:\/\/unwiredlabs.com\/blog\/wp-content\/uploads\/2014\/07\/aws_high_availability_in_cloud.jpg","articleSection":["Engineering"],"inLanguage":"en-US","potentialAction":[{"@type":"CommentAction","name":"Comment","target":["https:\/\/unwiredlabs.com\/blog\/getting-to-100-percent-uptime\/#respond"]}]},{"@type":"WebPage","@id":"https:\/\/unwiredlabs.com\/blog\/getting-to-100-percent-uptime\/","url":"https:\/\/unwiredlabs.com\/blog\/getting-to-100-percent-uptime\/","name":"High availability for tech startup - 100% uptime","isPartOf":{"@id":"https:\/\/unwiredlabs.com\/blog\/#website"},"primaryImageOfPage":{"@id":"https:\/\/unwiredlabs.com\/blog\/getting-to-100-percent-uptime\/#primaryimage"},"image":{"@id":"https:\/\/unwiredlabs.com\/blog\/getting-to-100-percent-uptime\/#primaryimage"},"thumbnailUrl":"https:\/\/unwiredlabs.com\/blog\/wp-content\/uploads\/2014\/07\/aws_high_availability_in_cloud.jpg","datePublished":"2014-06-15T06:51:42+00:00","dateModified":"2014-09-06T05:58:56+00:00","breadcrumb":{"@id":"https:\/\/unwiredlabs.com\/blog\/getting-to-100-percent-uptime\/#breadcrumb"},"inLanguage":"en-US","potentialAction":[{"@type":"ReadAction","target":["https:\/\/unwiredlabs.com\/blog\/getting-to-100-percent-uptime\/"]}]},{"@type":"ImageObject","inLanguage":"en-US","@id":"https:\/\/unwiredlabs.com\/blog\/getting-to-100-percent-uptime\/#primaryimage","url":"https:\/\/unwiredlabs.com\/blog\/wp-content\/uploads\/2014\/07\/aws_high_availability_in_cloud.jpg","contentUrl":"https:\/\/unwiredlabs.com\/blog\/wp-content\/uploads\/2014\/07\/aws_high_availability_in_cloud.jpg","width":400,"height":300},{"@type":"BreadcrumbList","@id":"https:\/\/unwiredlabs.com\/blog\/getting-to-100-percent-uptime\/#breadcrumb","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"https:\/\/unwiredlabs.com\/blog\/"},{"@type":"ListItem","position":2,"name":"Getting to 100% uptime"}]},{"@type":"WebSite","@id":"https:\/\/unwiredlabs.com\/blog\/#website","url":"https:\/\/unwiredlabs.com\/blog\/","name":"The Unwired Labs Blog","description":"","publisher":{"@id":"https:\/\/unwiredlabs.com\/blog\/#organization"},"potentialAction":[{"@type":"SearchAction","target":{"@type":"EntryPoint","urlTemplate":"https:\/\/unwiredlabs.com\/blog\/?s={search_term_string}"},"query-input":{"@type":"PropertyValueSpecification","valueRequired":true,"valueName":"search_term_string"}}],"inLanguage":"en-US"},{"@type":"Organization","@id":"https:\/\/unwiredlabs.com\/blog\/#organization","name":"The Unwired Labs Blog","url":"https:\/\/unwiredlabs.com\/blog\/","logo":{"@type":"ImageObject","inLanguage":"en-US","@id":"https:\/\/unwiredlabs.com\/blog\/#\/schema\/logo\/image\/","url":"https:\/\/unwiredlabs.com\/blog\/wp-content\/uploads\/2025\/08\/cropped-Unwired-labs-logo-rectangle.png","contentUrl":"https:\/\/unwiredlabs.com\/blog\/wp-content\/uploads\/2025\/08\/cropped-Unwired-labs-logo-rectangle.png","width":400,"height":200,"caption":"The Unwired Labs Blog"},"image":{"@id":"https:\/\/unwiredlabs.com\/blog\/#\/schema\/logo\/image\/"}},{"@type":"Person","@id":"https:\/\/unwiredlabs.com\/blog\/#\/schema\/person\/7340c085bb8b318dd3e8f44272ff67db","name":"Aravind","image":{"@type":"ImageObject","inLanguage":"en-US","@id":"https:\/\/unwiredlabs.com\/blog\/#\/schema\/person\/image\/","url":"https:\/\/secure.gravatar.com\/avatar\/3b5f84db6919959ece5096fd6e5cdf8b23a6a514bd5405a9def531548ad9985b?s=96&d=blank&r=g","contentUrl":"https:\/\/secure.gravatar.com\/avatar\/3b5f84db6919959ece5096fd6e5cdf8b23a6a514bd5405a9def531548ad9985b?s=96&d=blank&r=g","caption":"Aravind"},"sameAs":["https:\/\/x.com\/findinggopi"],"url":"https:\/\/unwiredlabs.com\/blog\/author\/admin\/"}]}},"_links":{"self":[{"href":"https:\/\/unwiredlabs.com\/blog\/wp-json\/wp\/v2\/posts\/68","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/unwiredlabs.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/unwiredlabs.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/unwiredlabs.com\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/unwiredlabs.com\/blog\/wp-json\/wp\/v2\/comments?post=68"}],"version-history":[{"count":0,"href":"https:\/\/unwiredlabs.com\/blog\/wp-json\/wp\/v2\/posts\/68\/revisions"}],"wp:attachment":[{"href":"https:\/\/unwiredlabs.com\/blog\/wp-json\/wp\/v2\/media?parent=68"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/unwiredlabs.com\/blog\/wp-json\/wp\/v2\/categories?post=68"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/unwiredlabs.com\/blog\/wp-json\/wp\/v2\/tags?post=68"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}