DEV Community: Amit chakraborty

Let’s Build Your First Electron App: The Magical Feed App!

Amit chakraborty — Mon, 14 Sep 2026 09:29:39 +0000

Hey there, future tech wizards! 🧙‍♂️ Are you ready to dive into the world of coding and create your very own app? With just some simple HTML, CSS, and JavaScript, you’ll have a cool feed app up and running in no time! 🚀

Grab your magic wands (or keyboards), and let’s get started! ✨

🏗️ What You’ll Need:

A Computer 💻 (Windows or Mac)
Electron (Don’t worry, we’ll get that for you!)
A Fun Spirit 😊 (That’s the most important part!)

📂 Let’s Create Our Project Folder! 📁

Make a New Folder:

Name it FeedApp (this is where all the magic will happen! 🎩).

Inside theFeedApp folder, create these files:

main.js
index.html
styles.css
renderer.js
feed.json

Your folder should look like this:

FeedApp/├── electron.exe├── feed.json├── index.html├── main.js├── styles.css└── renderer.js

📜 Step 1: Let’s Set Up Our Magical JSON! ✨

Create a file namedfeed.json in the FeedApp folder.

Add this super simple content:

{ "posts": []}

This file is like a treasure chest where we’ll store all our awesome posts! 🏴‍☠️

Say Goodbye to Git Woes: Become a Git Wizard Today! ‍♂️

Amit chakraborty — Mon, 14 Sep 2026 09:29:27 +0000

Git isn’t just a tool; it’s a superpower. Whether you’re a beginner or an experienced developer, mastering Git practices will transform your coding game. This guide will take you from Git rookie to Git wizard, ensuring every commit, branch, and merge is purposeful and polished. Let’s dive into the magic! 🪄

Why Do Git Conventions Matter? 🤔

Without conventions, you face:

Confusing Branch Names: Ever seen final-final2-real-final? 😵
Vague Commits: Messages like Fixed stuff or Updated code are useless.
Merge Nightmares: Unstructured workflows lead to conflicts galore.

Benefits of Conventions 🌟

Clarity: Instantly understand what’s happening.
Collaboration: Teams can work together seamlessly.
Automation: Simplify CI/CD pipelines.
Knowledge Sharing: New teammates onboard faster.
Confidence: Handle conflicts and workflows with ease.

🚀 Git Branch Naming: The Golden Rules

The Good ✅

Be Descriptive:

Good: feature/user-auth
Bad: branch1, asdf

Use Kebab Case:

Good: hotfix/fix-login-issue
Bad: hotfix_fixLoginIssue

Stick to Lowercase:

Good: bugfix/navbar-alignment
Bad: BugFix/NavbarAlignment

Keep It Short:

Good: feature/add-profile-pic
Bad: feature/this-is-a-really-long-branch-name-for-profile-pic

Avoid Unnecessary Hyphens:

Good: feat/update-readme
Bad: feat/update--readme--

Prefixes for Organization 🗂️

feature/: New features (e.g., feature/payment-gateway)
bugfix/: Fixes (e.g., bugfix/navbar-crash)
hotfix/: Critical production fixes
release/: Release preparation
docs/: Documentation changes

Include Ticket IDs 🔗

If you use Jira or GitHub Issues, reference the ticket:

Good: feature/PROJ-123-add-footer
Bad: feature/add-footer

The Bad Examples ❌

temp (What does this mean?)
final (Spoiler: It’s never final.)
xyz-bug (Which bug?)

📝 Commit Messages: Say More with Less

The Perfect Format ✍️

():

[optional body]

[optional footer]

Subject Line Rules 🧾

Use Imperative Mood:

Good: fix: resolve login bug
Bad: fixed login bug

Keep It Short (50 Characters Max):

Good: feat: add dark mode
Bad: Added a toggle for dark mode to the settings.

Capitalize the First Word:

Good: Refactor: optimize database queries
Bad: refactor: optimize database queries

Avoid Trailing Periods:

Good: style: fix header spacing
Bad: style: fix header spacing.

Body and Footer Tips 🖊️

Explain Why, Not Just What:

Example:
feat: add email notifications Added email notifications to improve user engagement by 20%.

Use 72-Character Line Wraps:

Avoid massive walls of text.

Reference Issues or Changes:

Example:
fix: correct cart calculation Resolves #456

Breaking Changes:

Use ! and explain:
chore!: drop Node.js 10 support BREAKING CHANGE: Now requires Node.js 12+.

🛠️ Handling Large Features

Break It Down:

Example: Split user-auth into login, registration, and password-reset.

Branch for Sub-Features:

Good: feature/login-page

Commit Frequently but Purposefully:

Commit only meaningful progress.

🔮 Advanced Git Commands: Mastery Awaits

1. git stash

Save changes for later:
git stash
Reapply stashed changes: git stash apply

2. git rebase

Rewrite history to keep it clean:
git rebase main
Resolve conflicts:
git rebase --continue

3. git cherry-pick

Apply specific commits:
git cherry-pick

4. git reset

Soft Reset (Keep changes):
git reset --soft HEAD~1
Hard Reset (Discard changes):
git reset --hard HEAD~

5. git merge

Merge without fast-forwarding:
git merge --no-ff
Resolve conflicts and finalize:
git merge --continue

6. Handling Merge Conflicts

Git highlights conflicts with >>>.
Resolve them manually.
Mark resolved files: git add git commit
Abort if needed: git merge --abort

7. Ignoring Files

Add to .gitignore:
*.log build/
Example: Ignore everything but a specific file:
* !important-file.txt

🌟 GitHub Pro Tips for Wizards

Automate with Change-logs : Use tools like conventional-changelog.
Use Pull Request Templates: Standardize reviews and approvals.
Setup Git Hooks: Example with Husky -> npx husky-init && npm install
GitHub CLI: Manage issues, PRs, and more directly from your terminal.

📚 References

sources

article: Git Branching Name Convention
article: Conventional Commits 1.0.0
article: Commit Message Guideline
article: A Successful Git Branching Model
image: dev.to/A Simplified Convention for Naming Branches and Commits in Git

🎯 Conclusion

Git is a skill that grows with practice. From mastering commands to crafting perfect commits, every small effort adds up. Embrace these best practices to streamline your workflow, reduce conflicts, and create a collaborative environment your team will love. Now, go forth and Git good! 🌟

Hermes Bytecode and the Cold-Start Budget: Engineering Time-to-Interactive as a Product Requirement

Amit chakraborty — Mon, 14 Sep 2026 08:21:40 +0000

In the lifecycle of a mobile application, the most expensive milliseconds are the ones that occur…

Reactnative #Webdev

In the lifecycle of a mobile application, the most expensive milliseconds are the ones that occur between the user tapping the icon and the first meaningful interaction. In my eight years of professional software engineering, I have seen these milliseconds treated as a secondary performance metric — a line item on a dashboard to be monitored but rarely governed.

When I joined Synapsis Medical Technologies as the first engineering hire, I was tasked with building a HealthTech AI platform from the ground up. We were operating in a high-stakes clinical environment where latency wasn’t just a nuisance; it was a barrier to care. I owned the React Native architecture from 0 to 1, and it became clear that if we wanted to serve clinical AI reliably, we had to treat Time-to-Interactive (TTI) not as a metric, but as a hard product requirement.

The primary lever for controlling TTI in the React Native ecosystem is the Hermes engine and its approach to ahead-of-time (AOT) compilation. Understanding how Hermes bytecode interacts with the cold-start budget is fundamental to shipping high-performance cross-platform software.

The Bottleneck: The JavaScript-to-Native Bridge

Traditional JavaScript engines on mobile, like JavaScriptCore (JSC), operate on a Just-In-Time (JIT) compilation model. When the application launches, the engine must fetch the JavaScript bundle from disk, parse the source code into an Abstract Syntax Tree (AST), and then compile it into bytecode before execution can even begin.

In a production environment, this creates a massive spike in CPU utilization and memory consumption during the most critical phase of the user journey. For a large-scale application — like the 18+ production apps I have shipped across iOS and Android — this parsing and compilation phase can easily consume several seconds on mid-range hardware.

Hermes changes this paradigm by shifting the compilation step from the user’s device to the build machine. By the time the application is packaged, the JavaScript has already been transformed into highly optimized Hermes bytecode.

The Architecture of Hermes Bytecode

The core advantage of Hermes is its ability to be memory-mapped. In a JIT environment, the entire compiled bytecode must reside in RAM. With Hermes, the bytecode is designed so that it can be mapped into memory without being eagerly loaded.

When I led the architecture at Synapsis, we integrated React Native with a HIPAA-aligned RAG/LLM pipeline. The complexity of the frontend state management, combined with FHIR/HL7 data parsing, meant our bundle sizes were substantial. If we had relied on JSC, the heap pressure during startup would have led to frequent Out-of-Memory (OOM) crashes on older Android devices.

Hermes bytecode is structured into a specific format:

01Function Headers: Metadata about the functions contained within the bundle.
02Small Values: A pool for immediate values and small constants.
03Large Values/Strings: A deduplicated string table that reduces the footprint of repeated identifiers.
04Bytecode Instructions: The actual executable logic.

Because this format is stable and predictable, the Hermes VM can “page in” only the bytecode required for the initial screen. This is the difference between loading a 10MB file into memory versus mapping a 10MB file and reading 400KB to render the login screen.

Engineering the Cold-Start Budget

Treating TTI as a product requirement means establishing a “cold-start budget.” If the requirement is a 1.5-second TTI, and the native OS overhead takes 400ms, you are left with 1.1 seconds for the React Native runtime and your application logic.

During my time scaling the engineering team at Synapsis from 0 to 21 engineers, we had to enforce strict discipline around this budget. As we added features like wearables integration and real-time clinical AI feedback, the temptation to add “just one more” heavy library was constant.

To maintain our budget, we focused on three technical levers:

1. Bytecode Pre-compilation and Stripping

We ensured that our CI/CD pipeline, which I overhauled to cut release cycles from 2 days to 4 hours, included a dedicated step for Hermes optimization. By using the -O flag during the hermesc compilation, we allowed the compiler to perform constant folding and dead-code elimination at the bytecode level.

2. The Impact of String Deduplication

In React Native, a significant portion of the bundle is often taken up by object keys in JSON structures or localized strings. Hermes’ bytecode format deduplicates these strings globally. When we integrated complex FHIR (Fast Healthcare Interoperability Resources) schemas, we saw a measurable decrease in bundle size compared to JSC because the repetitive keys in the FHIR JSON were stored only once in the Hermes string table.

3. Avoiding the “Require” Waterfall

Even with Hermes, the order of execution matters. If your index.js imports a heavy visualization library that isn't needed until three screens deep, the VM still has to process the initialization logic of that library. We moved toward a pattern of deferred initialization, ensuring that the initial bytecode execution path was as linear and shallow as possible.

Worked Example: Optimizing a Clinical AI Dashboard

Consider a scenario where an application needs to initialize a secure RAG (Retrieval-Augmented Generation) pipeline for clinical data. At Synapsis, we ran these pipelines with 99.9% uptime, but the client-side initialization was a potential bottleneck.

A typical (non-optimized) entry point might look like this:

javascript

// index.jsimport { AppRegistry } from 'react-native';import App from './App';import { ComplexAIProvider } from 'heavy-ai-sdk'; // 1.2MB of JSimport { LargeChartLibrary } from 'chart-suite'; // 800KB of JS

const Root = () => (   );

AppRegistry.registerComponent('Main', () => Root);

In this setup, even with Hermes, the VM must resolve the imports for the AI SDK and the Chart Library before the App can mount. To stay within our cold-start budget, we refactored to use dynamic imports and specialized bytecode splitting:

javascript

// index.jsimport { AppRegistry } from 'react-native';import React, { Suspense, lazy } from 'react';

// Keep the entry point leanconst App = lazy(() => import('./App'));

const Root = () => ( }>  );

AppRegistry.registerComponent('Main', () => Root);

By deferring the loading of the heavy AI and charting modules, we ensured that the Hermes VM only mapped the bytecode necessary for the LoadingScreen and the basic App shell. The result was a TTI that remained consistent even as the underlying platform grew in complexity.

What it Cost to Learn

The transition to a bytecode-first mindset isn’t free. During the CI/CD overhaul where I reduced our release cycles, I learned that debugging Hermes bytecode requires a different set of tools. Source maps become non-negotiable. When a crash occurs in a production environment, the stack trace refers to bytecode offsets, not line numbers in your JavaScript source.

Furthermore, Hermes does not support with statements or certain dynamic evaluation patterns like eval(). While these are generally considered bad practices in modern JavaScript, many legacy npm packages still use them. We had to perform rigorous audits of our dependency tree to ensure compatibility, a process that became a standard part of our architectural review as we scaled the team.

Practical Recommendations for Systems Architects

If you are managing a React Native stack and TTI is slipping, I recommend the following protocol based on my experience shipping 18+ production systems:

01Profile the Bytecode, Not Just the JS: Use the Hermes toolchain to analyze your .hbc files. Look for unexpectedly large string tables or function counts that indicate a leak of unnecessary code into the production bundle.
02Enforce CI/CD Gating: We implemented automated checks in our pipeline. If a Pull Request increased the Hermes bytecode size by more than 5%, it required a manual architectural sign-off. This prevented “dependency creep.”
03Prioritize Memory Mapping over Heap Allocation: Use the Intl APIs provided by Hermes rather than polyfilling large libraries like moment.js or lodash. The native implementations are more efficient at the bytecode level.
04Monitor the Native-to-JS Bridge: Even with optimized bytecode, a congested bridge will kill your TTI. Ensure that your initial render does not require multiple asynchronous round-trips to the native side.

Conclusion

Performance is not a feature you can bolt on at the end of a sprint; it is an architectural decision made at the beginning. By leveraging Hermes bytecode, we were able to deliver a high-uptime, HIPAA-aligned AI platform that felt instantaneous to the clinicians using it.

Treating the cold-start budget as a product requirement forced us to be intentional about every library we added and every abstraction we built. In the modern mobile landscape, where user attention is the scarcest resource, those saved milliseconds are the highest ROI investment an engineering team can make.

Amit Chakraborty is a founding engineer and senior architect — React Native, AI/RAG systems and production architecture. Portfolio: www.amitchakraborty.dev · LinkedIn · GitHub. Open to senior and founding engineering roles, remote worldwide.

Achieving 60fps on Budget Android Hardware: Offloading Image Decode and ML Preprocessing

Amit chakraborty — Mon, 14 Sep 2026 08:21:35 +0000

https://amitchakraborty.dev/blog/60fps-on-a-100-dollar-android-phone

In my eight years of professional software engineering, I have found that the true test of an architecture is not how it performs on a $1,200 flagship device, but how it holds up on a $100 Android handset. During my time as the founding engineer at Synapsis Medical Technologies, where I owned the React Native and Next.js architecture from 0 to 1, I faced a specific challenge: delivering real-time clinical AI insights on low-end mobile hardware without dropping frames.

When building a HealthTech AI platform, the user interface cannot afford to stutter. If a clinician is using a mobile device to capture diagnostic images or interact with a HIPAA-aligned RAG pipeline — which I scaled to 99.9% uptime — the feedback loop must be instantaneous. On budget hardware, the JavaScript thread is a precious commodity. If you task it with image decoding or machine learning (ML) preprocessing, the UI will freeze, the framerate will plummet to 15fps, and the application will become unusable.

The Bottleneck: The JavaScript Bridge and Main Thread Contention

The standard React Native architecture often falls into a trap where the JavaScript thread becomes the orchestrator for heavy data processing. On a budget Android device, the CPU is frequently a low-power ARM Cortex-A53 or A55. These chips have limited single-core performance.

When an image is captured or retrieved from a remote clinical database, it typically exists as a Base64 string or a local file URI. If you attempt to decode this image or resize it for an ML model — such as a TensorFlow Lite (TFLite) classifier — within the standard JS execution context, you trigger a cascade of performance failures:

GC Pressure: Large byte arrays in JS trigger frequent Garbage Collection cycles.
Bridge Congestion: Passing large amounts of image data across the React Native bridge creates a bottleneck that delays UI updates.
Main Thread Blockage: On Android, the UI thread and the JS thread compete for cycles on the same limited cores.

To maintain a consistent 60fps, the JS thread must be reserved strictly for business logic and UI state management. Everything else — decoding, color space conversion, and tensor preparation — must move to the background.

Moving Image Decode Off-Thread

The first step in reclaiming the 60fps target is removing image decoding from the JS-to-Native bridge. In my experience shipping 18+ production applications, I have seen developers attempt to use standard components for high-frequency updates, only to see the "flicker" of the placeholder as the native side struggles to decode the buffer.

On budget Android devices, we bypass the bridge using JSI (JavaScript Interface). Instead of sending a Base64 string, we send a memory pointer or a file descriptor. We then utilize the Android BitmapFactory within a dedicated background thread pool.

By offloading the decode to Schedulers.io() or a custom ThreadPoolExecutor in Java/Kotlin, we ensure that the heavy lifting of turning compressed JPEG/PNG bytes into a raw pixel array does not touch the UI thread.

ML Preprocessing: The Hidden Performance Killer

In the HealthTech AI platform I built, we integrated wearables and clinical data into RAG/LLM pipelines. Often, this required local preprocessing of visual data before sending it to an inference engine.

ML models rarely take a standard camera output. They require specific dimensions (e.g., 224x224), specific color formats (RGB vs. BGR), and normalized float values (0.0 to 1.0). If you perform this normalization in JavaScript by iterating over a pixel array, you are effectively killing the application’s performance. A 224x224 image has 50,176 pixels. Iterating through three color channels means 150,528 operations per frame. On a $100 phone, this takes well over 16ms, making 60fps mathematically impossible.

The solution is to move this logic into C++ using the NDK (Native Development Kit) and link it via JSI.

The Architecture: JSI and Native Buffers

By using JSI, we can expose C++ functions directly to JavaScript. This allows us to pass a SharedArrayBuffer or a reference to a native HardwareBuffer.

// Example of a Native Preprocessing Hook via JSIjsi::Value preprocessImage(jsi::Runtime& rt, const jsi::Object& buffer) { // 1. Get pointer to the raw image data auto array = buffer.getPropertyAsObject(rt, "data").getArrayBuffer(rt); uint8_t* pixelData = array.data(rt);

// 2. Perform resizing and normalization in C++ using SIMD instructions // This happens off the JS thread in a background worker dispatch_to_background([=]() { fast_resize_and_normalize(pixelData, targetBuffer); // 3. Trigger a callback when the tensor is ready for inference });

return jsi::Value::undefined();}

This approach allows the JS thread to remain idle while the CPU’s secondary cores handle the mathematical transformations.

Architecture and Trade-offs

When I scaled the engineering team at Synapsis from 0 to 21 engineers in 13 months, one of the primary technical hurdles was balancing feature velocity with this level of low-level optimization.

The Trade-off: Development Speed vs. PerformanceWriting JSI wrappers and C++ kernels is significantly slower than writing pure TypeScript. For 80% of applications, this is overkill. However, when your target demographic uses hardware with limited thermal headroom and weak GPUs, this native overhead is the only way to achieve a “premium” feel.

Memory ManagementMoving data to the native side introduces the risk of memory leaks. Unlike the JavaScript environment, where the garbage collector handles cleanup, manual memory management of HardwareBuffers or DirectByteBuffers is required. We implemented a pooling strategy where we reused a set of pre-allocated buffers to prevent the overhead of frequent allocations, which is particularly expensive on low-end Android kernels.

Worked Example: Real-time Signal Processing

Consider a scenario where the app must process a 30fps camera feed for a clinical diagnostic tool.

The Naive Way: Camera frame -> Base64 -> JS Bridge -> JS map() for normalization -> Bridge -> TFLite.
Result: 8–12 fps, device overheating, UI freezes.
The Optimized Way: Camera frame -> ImageReader (Native) -> YUV to RGB conversion (RenderScript or Vulkan) -> Native Tensor Buffer -> TFLite.
Result: 60fps UI, 30fps inference, stable thermals.

By using ImageReader on the native side, we can access the image planes directly in memory. We then use a JSI reference to tell the JS thread that a new frame is "ready." The JS thread only needs to update a small piece of state to trigger a re-render of the overlay, while the heavy processing happens entirely in the background.

What it Cost to Learn

Building this infrastructure taught me that CI/CD is just as important for performance as the code itself. When I overhauled our CI/CD across 5 production systems to cut release cycles from 2 days to 4 hours, I integrated automated performance profiling.

We discovered that even a minor change in how the React tree was structured could cause “over-rendering” that, when combined with our native processing, would push the CPU over its limit. We learned that on budget hardware, you cannot treat the JS thread and the Native thread as independent; they share the same hardware limitations. If the native side uses 70% of the CPU, the JS thread only has 30% left to maintain the UI.

We had to implement a “frame budget” system. If the native processing took longer than 10ms, we would intentionally drop the inference frequency to 15fps while keeping the UI at 60fps. This ensured the user experience remained fluid even if the AI analysis lagged slightly behind.

Practical Recommendations

For engineers tasked with supporting low-end Android devices, I recommend the following:

Avoid Base64: Never pass images across the bridge as strings. Use file URIs or, preferably, JSI-wrapped memory pointers.
Use the NDK for Math: If you are doing anything more complex than a basic array sort, move it to C++. The performance delta on low-end ARM chips is massive.
Profile on Real Hardware: Emulators are deceptive. A $100 phone has different thermal throttling profiles and disk I/O speeds than a high-end workstation.
Offload Image Loading: Use libraries like Glide or Fresco on the native side, but configure them to use a custom, lower-priority thread pool so they don’t starve the UI thread.
Pre-allocate Tensors: Allocation is expensive. Pre-allocate your input and output buffers for ML models at startup.

Conclusion

Achieving 60fps on a $100 Android phone is not a matter of writing “better” JavaScript; it is a matter of writing less JavaScript. By moving image decoding and ML preprocessing into the native layer and utilizing JSI for low-latency communication, we can provide a high-end experience on budget hardware. In my work building HIPAA-aligned AI systems and scaling complex architectures, this separation of concerns has been the defining factor in delivering software that is both powerful and accessible.

Amit Chakraborty is a founding engineer and senior architect — React Native, AI/RAG systems and production architecture. Portfolio:www.amitchakraborty.dev·LinkedIn·GitHub. Open to senior and founding engineering roles, remote worldwide.

Migrating to React Native Skia without a feature freeze

Amit chakraborty — Fri, 11 Sep 2026 16:30:02 +0000

I was three weeks out from a major release at Synapsis Medical Technologies when our real-time ECG visualiser started dropping frames on mid-range Android devices. We were using the standard React Native View and Path components from react-native-svg to render live waveform data from wearables. As the data points scaled, the bridge traffic spiked. The UI thread would lock up for 200ms every time the chart updated, causing the entire app to stutter.

We couldn't stop feature development for a month to rewrite the rendering layer. We had clinical AI features in flight and a HIPAA-aligned RAG pipeline to maintain. A total rewrite of our visualisation engine would have cost us two weeks of dev time and a high risk of regression in the clinical data display.

Instead of a "big bang" migration, we moved to react-native-skia (version 0.1.x at the time) by running it side-by-side with our existing SVG implementation. This allowed us to verify the rendering accuracy against our FHIR-compliant data sources before switching the flag.

Why the bridge fails at high-frequency rendering

In a standard React Native architecture (pre-Fabric or without JSI-based libraries), every time you update a component, the data travels across the bridge. If you are rendering a 60fps waveform, you are serialising and deserialising a massive JSON object of coordinates 60 times a second.

react-native-skia bypasses this by using JSI (JavaScript Interface) to provide direct access to the Skia graphics engine in C++. The reason you migrate isn't just "performance"—it's memory stability. In our case, the react-native-svg approach saw memory usage climb by 150MB over ten minutes due to the sheer volume of stringified path data being held in the bridge queue.

The incremental migration fix

This process allows you to swap the rendering engine for specific high-cost components without touching the rest of your UI tree.

1. Identify the draw-call bottleneck

Do not migrate your entire app. Use the Flashlight tool or the built-in React DevTools Profiler to find the specific component where the "Commit" phase is exceeding 16ms. In our case, it was the WaveformContainer.

2. Create a Dual-Engine Wrapper

Instead of replacing the component, wrap it. This allows you to A/B test the rendering and fall back instantly if the Skia C++ layer crashes on a specific Android NDK version.

// WaveformRenderer.tsx
import { Canvas, Path, Skia } from "@shopify/react-native-skia";
import { Svg, Path as SvgPath } from "react-native-svg";

interface Props {
  points: string;
  useSkia: boolean;
  width: number;
  height: number;
}

export const WaveformRenderer = ({ points, useSkia, width, height }: Props) => {
  if (useSkia) {
    // We pre-parse the path to avoid doing it inside the render cycle
    const skiaPath = Skia.Path.MakeFromSVGString(points);
    return (
      <Canvas style={{ width, height }}>
        <Path path={skiaPath} color="blue" style="stroke" strokeWidth={2} />
      </Canvas>
    );
  }

  return (
    <Svg width={width} height={height}>
      <SvgPath d={points} stroke="blue" strokeWidth={2} />
    </Svg>
  );
};

How to confirm: Run the app on an Android emulator with "Show GPU Overdraw" enabled. The Skia Canvas will appear as a single drawing layer, whereas the SVG approach will often show multiple nested boxes if you are using complex groups.

3. Move to Skia Values for Animation

If you pass React state into a Skia Canvas, you are still hitting the React render cycle. To get the 60fps performance, you must use useSharedValue from react-native-reanimated or useValue from Skia.

import { useValue, Canvas, Circle } from "@shopify/react-native-skia";

const MyComponent = () => {
  const cx = useValue(0); // This stays on the UI thread

  // Confirm this works by checking that the React component 
  // does NOT re-render (log a message in the body) 
  // while the animation runs.
  return (
    <Canvas style={{ flex: 1 }}>
      <Circle cx={cx} cy={100} r={50} color="red" />
    </Canvas>
  );
};

4. Shadow Rendering for Validation

Before we shipped to clinicians, we ran both engines in a hidden internal build. We rendered the Skia output and the SVG output on top of each other with 50% opacity. If they didn't align perfectly, we knew our coordinate scaling logic was flawed.

The cost of the Skia abstraction

Skia is not a silver bullet. Adding @shopify/react-native-skia adds approximately 4MB to 8MB to your final APK/IPA size because it bundles the Skia binary.

In my experience, you should avoid Skia for:

Simple icons: The overhead of the Skia context is higher than just using a standard Image or SVG.
Text-heavy layouts: Skia's text engine requires you to manage typefaces and glyphs manually. If you need accessibility features like screen readers to work out-of-the-box, stick to the standard Text component. We kept all our clinical labels in standard React Native Text components and only used Skia for the waveforms.

At your level

Starting out:
Focus on understanding the difference between the "Main thread" and the "JS thread". Use react-native-skia only when you see the JS thread FPS drop in the debug menu. Start by converting a single static shape before trying to animate.

Working engineer:
Implement a rendering strategy pattern. Don't hardcode Skia components. Use the wrapper approach I detailed above so you can toggle the engine via a remote config (like Firebase or LaunchDarkly). If a specific device manufacturer has a broken OpenGL implementation, you can kill the Skia engine for those users without a hotfix.

Senior or staff:
Audit the memory lifecycle of Skia objects. C++ objects created via Skia.Path.Make() are not managed by the JavaScript garbage collector in the same way. You must ensure you aren't recreating these objects inside a useMemo that triggers too frequently, or you will see the native memory footprint of your app steadily climb.

Lead or director:
Evaluate the impact on your CI/CD pipeline. Adding Skia requires native compilation. When I cut our release cycles from 2 days to 4 hours, one hurdle was the increased build time for native modules. Ensure your runners have enough concurrent power to handle the C++ compilation, or use pre-built binaries if your environment allows.

In the interview

The Question: "How do you handle high-frequency data visualisation in React Native without dropping frames?"

Weak Answer: "I would use Skia because it's faster and uses the GPU." This is weak because it doesn't explain why or what the trade-offs are regarding bundle size and complexity.

Strong Answer: A strong answer identifies that the bottleneck is usually the bridge or the React render cycle. You should discuss moving the execution to the UI thread using JSI-based libraries like Skia or Reanimated. Mention the specific trade-off: you gain rendering performance but lose the high-level accessibility and layout features of the standard View system.

The Senior Follow-up: "How do you handle the memory management of C++ backed objects in Skia?"
The interviewer is looking for your awareness of the JSI lifecycle. Someone who has actually done this in production will talk about avoiding object creation in the render loop and the risks of memory leaks when passing large data sets from the JS heap to the C++ heap. They might mention that while JSI helps, you still need to be careful about the size of the data being passed across the JSI boundary if it's happening 60 times a second.

On-Device Computer Vision Under 16 Milliseconds

Amit chakraborty — Fri, 11 Sep 2026 08:30:02 +0000

In the development of clinical AI and real-time health monitoring, the difference between a functional interface and a broken user experience is measured in milliseconds. When I led the architecture for Synapsis Medical Technologies as the first engineering hire, I was tasked with building systems that bridged the gap between high-stakes medical data and immediate user feedback. Across the 18 production applications I have shipped, one constraint remains absolute: if you want a user to perceive a computer vision task as "real-time," you have exactly 16.6 milliseconds to complete your work.

This is the 60 FPS (frames per second) budget. In a browser or mobile environment, this budget must cover camera capture, frame preprocessing, model inference, post-processing, and the final UI render. If your inference takes 25ms, you have already failed the latency test, resulting in "jank" that erodes user trust—a critical failure in HealthTech.

To hit these targets, we are seeing a fundamental shift away from server-side inference toward on-device execution using MediaPipe and WebGPU. By moving the compute to the edge, we eliminate the 100ms–500ms round-trip latency of a network request, but we inherit the brutal constraints of mobile hardware.

The Problem: The Latency Floor

When building the architecture at Synapsis, where I owned the React Native, Next.js, and NestJS stack from 0 to 1, I encountered the "latency floor." Even with a highly optimized NestJS backend, a request originating from a mobile device on a 4G connection faces physical limitations.

For a computer vision task—such as detecting a patient's range of motion or analyzing a skin lesion—sending raw video frames to a cloud-based GPU is architecturally expensive. You face:

Ingress Costs: High-resolution frames consume significant bandwidth.
Privacy Concerns: Handling PHI (Protected Health Information) requires HIPAA-aligned pipelines. While I have maintained 99.9% uptime for HIPAA-aligned RAG pipelines, the most secure data is the data that never leaves the device.
Jitter: Network fluctuations make a consistent 60 FPS frame rate impossible.

The solution is to treat the client’s GPU as the primary compute resource. However, the traditional WebGL approach for browser-based AI is reaching its limits. WebGL was designed for drawing triangles, not for general-purpose parallel computation. This is where WebGPU changes the design requirements.

Context: The Shift to WebGPU and MediaPipe

The ecosystem has recently reached a tipping point. Chrome 113 introduced WebGPU by default, and MediaPipe has evolved from a C++ internal Google tool to a cross-platform framework that supports WebAssembly (Wasm) and WebGPU acceleration.

Unlike WebGL, which requires "faking" compute by storing data in textures and using fragment shaders, WebGPU provides direct access to GPU compute shaders. This allows for more efficient memory layouts and reduced overhead when passing data between the CPU and GPU. For engineers building React Native or web-based medical interfaces, this means we can now run models like BlazeFace or MediaPipe Landmarker at speeds that were previously reserved for native C++ implementations.

Technical Explanation: The 16ms Pipeline

To achieve sub-16ms latency, the pipeline must be non-blocking. In my experience scaling engineering teams and systems, the most common bottleneck isn't the model itself, but the data transfer between the CPU and GPU.

The pipeline generally follows this flow:

Texture Acquisition: The camera feed is uploaded to the GPU as a texture.
Preprocessing: Resizing, normalization, and color space conversion occur via compute shaders.
Inference: MediaPipe executes the model using the WebGPU backend.
Post-processing: Converting tensors back into human-readable coordinates or masks.
Rendering: Drawing the results onto a <canvas> or overlaying them on a React Native view.

If you use the CPU for step 2 or 4, you will likely exceed your 16ms budget. The "Zero-Copy" principle is essential here. You want the data to stay in GPU memory from the moment the camera captures the frame until the moment the result is rendered to the screen.

Architecture and Trade-offs

During my 8+ years of professional engineering, I have found that every performance gain comes with a trade-off in complexity or accuracy.

Quantization vs. Precision

To fit a model into the 16ms window, you often have to move from Float32 to Int8 or Float16 quantization. In a clinical AI context, this is a sensitive trade-off. A lower-precision model might run in 8ms instead of 20ms, but if it increases the error rate for a diagnostic tool, the speed is irrelevant. The architect's role is to define the "minimum viable precision" required for the use case.

Wasm vs. WebGPU

While WebGPU is faster, Wasm (WebAssembly) with SIMD (Single Instruction, Multiple Data) is more compatible across older devices. When I overhauled CI/CD cycles from 2 days to 4 hours, one of the primary goals was enabling rapid testing across a fragmented device landscape. If your user base is using five-year-old Android devices, a WebGPU-only architecture will fail. A hybrid approach—detecting WebGPU support and falling back to Wasm—is the standard for production-grade applications.

A Worked Example: Hand Tracking

Consider a scenario where we need to track 21 3D hand landmarks. Using MediaPipe’s WebGPU delegate, the initialization looks like this:

const vision = await FilesetResolver.forVisionTasks(
  "https://cdn.jsdelivr.net/npm/@mediapipe/tasks-vision/wasm"
);

const handLandmarker = await HandLandmarker.createFromOptions(vision, {
  baseOptions: {
    modelAssetPath: `hand_landmarker.task`,
    delegate: "GPU" // Forces WebGPU/WebGL usage
  },
  runningMode: "VIDEO",
  numHands: 2
});

The critical optimization happens in the animation loop. Using requestAnimationFrame, we must ensure the detectForVideo call returns within our budget. If the inference takes 12ms, we have 4.6ms left for UI updates. In a React environment, this means avoiding state updates that trigger heavy re-renders. Instead, we should use useRef to hold the landmark data and update a Canvas API directly, bypassing the React reconciliation engine for the high-frequency frame updates.

What it Cost to Learn

Building these systems at scale taught me that the "happy path" in documentation rarely survives production. When I scaled the Synapsis team from 0 to 21 engineers, we learned that the biggest performance killer wasn't the GPU—it was thermal throttling.

On mobile devices, running a GPU-intensive model at 60 FPS will heat the device rapidly. Within minutes, the OS will throttle the clock speed, and your 16ms inference time will balloon to 40ms. We had to implement "Adaptive Frame Rates." If the device temperature rose or the battery was low, we would drop the target to 30 FPS. This preserved the utility of the application at the cost of some smoothness, which is a necessary compromise in a professional environment.

Furthermore, integrating these vision tasks into a HIPAA-aligned environment meant ensuring that the frames processed in GPU memory were never cached or logged. Even on-device, data persistence must be strictly controlled.

Practical Recommendations

For architects looking to implement on-device vision, I recommend the following:

Profile the "Bus," not just the Model: Use Chrome DevTools' Performance tab to see how long texImage2D or device.queue.writeBuffer takes. Often, moving the data to the GPU takes longer than the actual inference.
Use Web Workers: Run the MediaPipe inference in a Dedicated Worker. This keeps the main thread free for user interactions, ensuring the UI remains responsive even if a frame takes longer than 16ms to process.
Optimize the CI/CD for Models: As I did with our production systems, automate the model quantization and conversion process. When a data scientist updates a model, the CI pipeline should automatically generate the Wasm and WebGPU-optimized versions, running automated latency benchmarks on real devices before the code is even reviewed.
Prioritize FHIR/HL7 Integration early: If the vision data needs to eventually reach a clinical record, ensure your post-processing step outputs data in a format compatible with healthcare standards. At Synapsis, integrating wearables and FHIR data was as important as the AI itself.

Conclusion

Achieving sub-16ms computer vision on the web is no longer an experimental feat; it is a requirement for modern, high-performance applications. By leveraging MediaPipe and WebGPU, we can build tools that were previously impossible without native development.

The transition from cloud-centric AI to edge-compute architecture requires a disciplined approach to the frame budget. As an architect, your job is to manage the tension between model accuracy, device thermal limits, and the unrelenting 60 FPS clock. When these elements are balanced, the result is a seamless, secure, and highly responsive user experience that respects both the user’s time and their data privacy.

Production failures: the things that page you · 1. The three in the morning page

Amit chakraborty — Fri, 11 Sep 2026 04:30:08 +0000

Production failures: the things that page you · Chapter 1 of 24 · Reliability · new chapter every Friday morning

By the end of this chapter: Read an unfamiliar dashboard under pressure and decide what to look at first.

Why this matters

When a pager goes off at three in the morning, adrenaline floods your system. Heart rate increases, cognitive focus narrows, and the brain defaults to pattern-matching rather than analytical reasoning. If you do not have a structured method for reading system state, this physiological response will force you down a rabbit hole. You will spend forty minutes investigating a minor CPU spike on a background worker while the primary database is completely unreachable.

Dashboards are almost always built by the engineers who wrote the application, which means they are designed to confirm the system is working, not to diagnose it when it is broken. They are dense with implementation details: garbage collection pauses, cache hit rates, queue depths, and thread counts.

Reading an unfamiliar dashboard under pressure requires ignoring ninety percent of what is on the screen. You must know exactly which three or four charts to look at first to isolate the fault domain. Without this discipline, you will guess at the root cause based on whichever chart looks the most erratic, prolonging the outage and exhausting yourself in the process.

Before you start

To execute the worked example and follow the technical reasoning in this chapter, you must have:

Docker and Docker Compose installed on your local machine.
Python 3.10 or higher installed.
A basic understanding of HTTP status codes (specifically the difference between 200, 400, and 500 series).
Familiarity with the concept of a time-series metric (a value recorded at a specific timestamp).

Bounding the problem from the outside in

The most common mistake in incident response is starting the investigation at the component you understand best, rather than the component closest to the user. If you are a database engineer, you look at database locks. If you are a frontend engineer, you look at the CDN.

You must evaluate the system from the outside in. The "outside" is the absolute edge of your infrastructure—usually a load balancer, an ingress controller, or an API gateway. The "inside" is the deepest layer of persistence.

When you open a dashboard, locate the metrics for the edge first. You are looking to answer a single, binary question: is traffic reaching our infrastructure at all? If the load balancer shows zero incoming requests, there is no point looking at application logs or database queries. The failure is upstream—perhaps a DNS failure, a revoked TLS certificate, or a severed transit link.

If traffic is reaching the edge, you move one layer inward to the application. If the application is receiving traffic but failing, you move to its dependencies. You only look at internal component metrics (like memory usage or thread counts) once you have proven that the layer above it is receiving requests and generating errors.

The three signals that dictate the investigation

Once you have identified the layer you are investigating, you must ignore custom business metrics and focus entirely on the RED signals: Rate, Errors, and Duration. These three metrics describe the experience of the consumer calling that layer.

Rate is the volume of requests per second. You are looking for sudden, sharp changes. A gradual increase is organic load; a vertical spike is a retry storm or a malicious attack. A sudden drop to zero means a pipe has broken upstream.

Errors are the rate of failed requests. In HTTP systems, this means 5xx status codes. You must explicitly filter out 4xx codes during initial triage. A spike in 4xx errors usually means a client deployed a bug and is sending malformed requests. A spike in 5xx errors means your infrastructure is failing to handle valid requests.

Duration is latency. You must never look at average latency. Averages hide catastrophic failures. If an endpoint serves 99 requests in 10 milliseconds, and one request hangs for 10,000 milliseconds before timing out, the average latency is 109 milliseconds. On a dashboard, 109ms looks like a healthy system. You must look at the 99th percentile (p99) latency. In that same scenario, the p99 latency is 10,000ms, which immediately tells you that a subset of users is experiencing total failure.

Correlating the signals to isolate the fault

Reading a dashboard is not about looking at one chart; it is about observing how Rate, Errors, and Duration move in relation to one another at the exact minute the alert fired. Their correlation tells you where to look next.

Scenario A: Rate remains flat, Duration spikes, Errors spike.
Traffic did not change, but suddenly the system got slow, and then it started throwing errors. This is the signature of resource exhaustion. A downstream dependency (like a database or a third-party API) slowed down. Your application threads waited for that dependency, holding open connections until they hit a timeout limit, at which point they returned 500 errors to the user. Do not look at application code; look at the downstream dependencies.

Scenario B: Rate spikes, Duration spikes, Errors spike.
This is a capacity failure. The system was overwhelmed by a sudden surge in traffic. The application ran out of CPU, memory, or network bandwidth trying to serve the load. The fix is usually to shed load, scale up, or block the offending traffic source.

Scenario C: Rate drops, Errors remain flat, Duration remains flat.
The system is fast and error-free, but nobody is using it. During peak hours, this is impossible. This means clients are failing to reach you. The fault domain is strictly upstream: DNS, BGP routing, or a misconfigured external firewall.

To see these correlations, you must control the time window of the dashboard. By default, dashboards often show the last 24 hours. A critical failure that began five minutes ago is invisible on a 24-hour graph; it looks like a single, tiny pixel. When you open the dashboard, immediately change the time window to start ten minutes before the alert fired, and end at the current time. This maximizes the visual contrast between "healthy" and "broken."

A worked example

This example simulates a production service that suddenly experiences a downstream dependency failure. We will spin up a Python application and a Prometheus instance to scrape its metrics. We will then trigger the failure and use PromQL (Prometheus Query Language) to triage the symptoms exactly as you would on a dashboard.

Create a directory named triage-example and create three files inside it.

1. app.py
This is our web server. It exposes metrics and a /simulate_outage endpoint.

import time
import random
import threading
from http.server import HTTPServer, BaseHTTPRequestHandler
from prometheus_client import start_http_server, Counter, Histogram

# RED Metrics
REQUEST_COUNT = Counter('http_requests_total', 'Total HTTP Requests', ['method', 'endpoint', 'status'])
REQUEST_LATENCY = Histogram('http_request_duration_seconds', 'HTTP Request Latency', ['endpoint'])

outage_active = False

class MetricsHandler(BaseHTTPRequestHandler):
    def do_GET(self):
        global outage_active
        start_time = time.time()

        if self.path == '/simulate_outage':
            outage_active = True
            self.send_response(200)
            self.end_headers()
            self.wfile.write(b"Outage simulation started.")
            return

        # Simulate normal traffic vs outage traffic
        if outage_active:
            # Downstream dependency is hanging, causing latency spikes and timeouts
            time.sleep(random.uniform(2.0, 5.0))
            status = 500
        else:
            # Normal operation
            time.sleep(random.uniform(0.01, 0.05))
            status = 200

        REQUEST_COUNT.labels(method='GET', endpoint='/api/data', status=status).inc()
        REQUEST_LATENCY.labels(endpoint='/api/data').observe(time.time() - start_time)

        self.send_response(status)
        self.end_headers()
        self.wfile.write(b"Response")

def generate_background_traffic():
    """Simulates users constantly hitting the API."""
    import urllib.request
    while True:
        try:
            urllib.request.urlopen('http://localhost:8080/api/data', timeout=10)
        except Exception:
            pass
        time.sleep(0.5)

if __name__ == '__main__':
    # Start Prometheus metrics server on port 8000
    start_http_server(8000)

    # Start background traffic generator
    threading.Thread(target=generate_background_traffic, daemon=True).start()

    # Start main application server on port 8080
    server = HTTPServer(('0.0.0.0', 8080), MetricsHandler)
    print("Server running. Metrics on port 8000, App on port 8080.")
    server.serve_forever()

2. prometheus.yml
This configures Prometheus to scrape our Python application.

global:
  scrape_interval: 2s

scrape_configs:
  - job_name: 'python_app'
    static_configs:
      - targets: ['app:8000']

3. docker-compose.yml
This wires the application and Prometheus together.

version: '3.8'
services:
  app:
    build: 
      context: .
      dockerfile_inline: |
        FROM python:3.10-slim
        RUN pip install prometheus_client
        COPY app.py .
        CMD ["python", "app.py"]
    ports:
      - "8080:8080"
      - "8000:8000"

  prometheus:
    image: prom/prometheus:v2.45.0
    volumes:
      - ./prometheus.yml:/etc/prometheus/prometheus.yml
    ports:
      - "9090:9090"

Execution and Triage:

Open your terminal in the triage-example directory and run: docker-compose up -d
Wait 30 seconds for background traffic to generate baseline metrics.
Open Prometheus in your browser at http://localhost:9090.
In the query bar, type the following to check the Rate and click "Execute", then switch to the "Graph" tab: rate(http_requests_total[10s]) You will see a steady line representing normal traffic.
In a new terminal window, trigger the failure: curl http://localhost:8080/simulate_outage
Wait 15 seconds.
Now, triage the system using the RED method by running these three queries in Prometheus:

Query 1: Errors
rate(http_requests_total{status="500"}[10s])
You will see errors spiking from zero to a high rate.

Query 2: Rate (Total Traffic)
sum(rate(http_requests_total[10s]))
You will notice the total rate of requests has actually dropped slightly. The clients are blocked waiting for the slow server.

Query 3: Duration (p99 Latency)
histogram_quantile(0.99, rate(http_request_duration_seconds_bucket[10s]))
You will see latency jump from ~0.05 seconds to over 4.0 seconds.

By reading these three signals, you have successfully triaged the failure: Rate is steady/dropping, Duration spiked, Errors spiked. This is Scenario A. You know instantly that a downstream dependency is hanging and exhausting your application's capacity to serve new requests.

Where people get stuck

Symptom: You stare at a dashboard full of CPU and memory charts, trying to find the anomaly, but everything looks slightly jagged and you cannot tell what is normal.
Fix: Stop looking at resource metrics. Switch immediately to the load balancer or API gateway dashboard and look at the HTTP status codes and latency. CPU is a resource; it only matters if it impacts the user. Find the user impact first, then look at the resources of the specific component serving those users.

Symptom: The alert says the API is down, but the application dashboard shows zero errors and extremely low latency.
Fix: You are looking at the wrong fault domain. If the application shows no errors and low traffic, the traffic is not reaching the application. Move upstream. Check the ingress controller, the WAF (Web Application Firewall), or the DNS routing metrics.

Symptom: A customer complains that the system is timing out, but the dashboard shows an average latency of 45 milliseconds.
Fix: Change the dashboard aggregation from average (or mean) to p99 or p99.9. Averages smooth out outliers. If 99% of your traffic is fast and 1% is timing out at 30 seconds, the average will hide the failure entirely. You must measure the worst-case experience.

Your tasks

Adjust the time window: In the Prometheus UI from the worked example, find the time controls (usually in the top right). Change the graph window from the default (1 hour) to 5 minutes. Observe how the transition from "healthy" to "broken" becomes much sharper and easier to read. 'Done' when you can clearly see the exact second the outage began on the graph.
Isolate the 4xx errors: Modify app.py so that when outage_active is true, it returns a 400 status code instead of 500, and keeps latency low (0.01s). Restart the docker container, trigger the outage, and write a PromQL query that proves the system is failing due to client errors, not server latency. 'Done' when your p99 latency query shows a flat line, but your error query shows a spike.
Simulate an upstream failure: Modify the generate_background_traffic function in app.py to completely stop sending requests when outage_active is true. Restart the system, trigger the outage, and use PromQL to diagnose it. 'Done' when you can prove via the rate() query that traffic has dropped to zero, while errors and latency remain flat.

Your tasks this week

Do the exercises above before the next chapter. Reading a tutorial and doing
one are different activities and only one of them changes what you can build.

Stuck on any of them? Say so — describe what you tried and what happened:
tell me where you got stuck. I read every one, and the questions
that come back more than twice get answered in the next chapter.

Production failures: the things that page you

Chapter 1 of 24. New chapter every Friday morning.
Next: Thundering herd: when the cache expires all at once.

· The full syllabus and every chapter so far
· Subscribers also get the condensed notes for this chapter, the running
recap of everything the series has covered, and the extended guidance:
subscribe

Written by Amit Chakraborty — founding engineer and senior architect: React Native, AI and RAG systems, production architecture. Portfolio · LinkedIn · GitHub.

Need this built, reviewed or taught to your team? Get in touch or email amit@devamit.co.in. Available for senior and founding engineering roles, consulting and training, remote worldwide.

The Cost of Silent Failures: Hardening the Contract Between React Native and NestJS

Amit chakraborty — Fri, 11 Sep 2026 04:30:03 +0000

In my eight years of professional software engineering, the most expensive bugs I have encountered were never syntax errors. They were "silent" contract drifts—instances where the backend changed a field from a required string to an optional one, or renamed a snake_case key to camelCase, and the mobile application simply ceased to function for a subset of users.

When you are shipping across iOS, Android, web, and desktop—as I have for 18 production applications—the surface area for these failures is massive. In a distributed system, the "truth" of your data is often a moving target. If your frontend and backend teams are operating on hand-written TypeScript interfaces that must be manually synchronized, you are not building a system; you are managing a game of telephone.

At Synapsis Medical Technologies, where I was the first engineering hire and led the architecture from 0 to 1, the stakes were elevated by the nature of HealthTech. We were handling HIPAA-aligned RAG (Retrieval-Augmented Generation) pipelines and integrating clinical data via FHIR/HL7. In that environment, a schema mismatch isn't just a UI glitch; it is a data integrity risk. To move fast without breaking clinical workflows, we had to move the "source of truth" out of the developer's head and into the build pipeline.

The Fragility of Manual Synchronization

The industry standard for years has been "copy-paste-adjust." A backend engineer updates a NestJS DTO (Data Transfer Object), and the mobile engineer attempts to mirror that change in a React Native interface.

This fails for three reasons:

The Latency of Human Communication: Even in high-performing teams, documentation lags behind code. By the time a Swagger/OpenAPI doc is updated, the breaking change might already be in a staging environment.
Type Erosion: TypeScript’s any or overly permissive interfaces allow developers to bypass strict checks when they are in a rush, leading to runtime crashes when a null value hits a component expecting a string.
The Multi-Platform Multiplier: If you are supporting React Native (iOS/Android) and Next.js (Web) simultaneously, you now have two separate codebases that must remain in sync with a single NestJS backend.

When I scaled the engineering team at Synapsis from 0 to 21 engineers in 13 months, I realized that manual synchronization was the primary bottleneck to our velocity. We needed a way to ensure that if the backend changed, the frontend would refuse to compile until the new contract was satisfied.

Context: The Shift to Schema-First Development

The broader ecosystem is moving toward automated contract enforcement. React Native 0.76 recently introduced the New Architecture as the default, emphasizing the Bridgeless mode and the "TurboModule" system which relies heavily on C++ generated code from TypeScript specs. This signals a shift: the industry is realizing that loosely typed boundaries are a performance and stability tax.

However, while React Native is hardening its internal bridge, the external bridge—the network layer—remains the wild west. Tools like tRPC have gained traction for monorepos, but they can be difficult to implement when dealing with complex, microservice-adjacent architectures or when integrating with specialized AI pipelines and wearables data. The goal is to achieve the "tRPC experience"—full end-to-end type safety—without sacrificing the flexibility of a standard REST or GraphQL API.

Architecture: The Single Source of Truth

In the architecture I owned, we utilized a "Schema-First" approach using NestJS as the generator. Instead of treating the backend and frontend as two distinct entities, we treated the API definition as a shared library.

The Mechanism: Generating the Client

We used NestJS's ability to output OpenAPI (Swagger) specifications not just for documentation, but as a build artifact. By integrating @nestjs/swagger, every time the backend code changed, a JSON schema was updated.

We then used an automated pipeline to ingest this schema and generate a TypeScript Fetch client. This client includes:

Strictly typed Request and Response objects.
Enum synchronization (preventing the "magic string" problem).
Path parameter validation.

The CI/CD Integration

To make this effective, the contract check must be part of the deployment pipeline. I led a CI/CD overhaul across five production systems that cut our release cycles from 2 days to 4 hours. A key component of this was "Contract Testing."

Before a backend PR could be merged, the pipeline would:

Generate the new API schema.
Run the frontend build against the new schema.
If the frontend failed to compile due to a type mismatch, the PR was blocked.

This moved the discovery of breaking changes from "Runtime in Production" to "Build Time in CI."

A Worked Example: Handling Clinical AI Responses

Consider a RAG pipeline serving clinical AI. At Synapsis, we ran a HIPAA-aligned RAG pipeline at 99.9% uptime. The data returned by these LLMs is non-deterministic, but the structure we wrap it in must be rigid.

On the backend (NestJS), we define the response:

export class ClinicalAnalysisResponse {
  @ApiProperty()
  @IsString()
  summary: string;

  @ApiProperty({ enum: EvidenceLevel })
  confidence: EvidenceLevel;

  @ApiProperty({ type: [SourceMetadata] })
  sources: SourceMetadata[];
}

If I decide to rename sources to citations to better align with medical terminology, the generated client on the React Native side immediately flags an error in every component using that data. In a manual workflow, we might miss one screen in the mobile app, leading to a "blank" state for the user. With a typed contract, the compiler is the auditor.

Trade-offs and Constraints

No architecture is without cost. Implementing strict typed contracts introduces specific frictions:

The Monorepo vs. Polyrepo Debate: This approach is significantly easier in a monorepo (using tools like Nx or Turborepo). In a polyrepo, you must manage versioned npm packages for your types, which introduces the "dependency hell" of ensuring the mobile app is using the correct version of the backend types.
Build Times: Generating clients and running cross-project type checks adds minutes to your CI pipeline. However, I found that the 10 minutes spent in CI is vastly cheaper than the 2 days spent debugging a production outage.
Over-Engineering for Small Teams: If you are a single developer, this might feel like overhead. But as I saw when scaling to 21 engineers, the overhead of not having this is exponential. Communication debt is the silent killer of velocity.

Practical Recommendations

For teams looking to harden their contracts between React Native and NestJS, I recommend the following:

Avoid any at the Network Boundary: Use zod or class-validator to validate incoming data at the NestJS controller level. If the data doesn't match the DTO, reject the request before it even hits your business logic.
Automate Client Generation: Do not write your useQuery hooks or fetch calls by hand. Use tools like openapi-typescript-codegen or rtk-query-codegen to create the API layer from your NestJS swagger output.
Treat Types as Versioned Artifacts: If you are not in a monorepo, publish your API client as a private package. The mobile app should explicitly upgrade its contract version.
Sync Enums, Not Just Interfaces: One of the most common points of failure is when the backend adds a new status to an enum (e.g., Status.PENDING_REVIEW) and the frontend logic only handles SUCCESS and FAILURE. Generated types force you to handle the exhaustive list of enum members.

Conclusion

The transition from 0 to 1 in a startup is about speed, but the transition from 1 to 100 is about stability. By implementing strictly typed contracts, we eliminated an entire class of bugs that previously plagued our release cycles.

Building 18 production applications has taught me that the code you write is less important than the interfaces you define. When the interface is a shared, enforced contract, the friction between backend and mobile teams evaporates. You stop arguing about what the API should return and start focusing on the value the data provides to the end user. Whether you are serving a simple CRUD app or a 99.9% uptime clinical AI pipeline, the cheapest place to catch a bug is always in the IDE, long before the first byte is sent over the wire.

MLOps: models that survive production · 1. Why models fail in production and never in the notebook

Amit chakraborty — Thu, 10 Sep 2026 16:30:11 +0000

MLOps: models that survive production · Chapter 1 of 12 · AI Engineering · new chapter every Thursday night

By the end of this chapter: Name the gap between an experiment and a running system.

Why this matters

A machine learning model is the only software artifact where the code can execute perfectly, throw no exceptions, return a valid response, and still be completely wrong.

When you write standard software, a bug usually results in a stack trace or a failed test. When you train a model in a Jupyter notebook, you are working in an environment designed for exploration, not execution. The notebook hides the complexity of state, time, and data distribution. You can achieve 99% accuracy on a static CSV file, but the moment that model is exposed to a production system—where data arrives asynchronously, schemas drift, and memory is stateless—it will fail.

Sometimes it fails loudly, crashing the service because a feature is missing. More often, it fails silently. It returns a prediction based on misaligned data types or leaked state, degrading the user experience while your monitoring dashboards show a 200 OK HTTP status.

If you do not understand the mechanical differences between an experimental notebook and a production runtime, you will deploy systems that require constant manual intervention. You will spend weeks debugging models that "worked on your machine." Naming and understanding this gap is the prerequisite for everything that follows in machine learning operations.

Before you start

To run the code and understand the concepts in this chapter, you must have:

Python 3.10 or higher installed.
scikit-learn==1.3.2, pandas==2.1.4, and numpy==1.26.2 installed in your environment.
An understanding of how to train a basic model using scikit-learn and how to make a prediction.
Familiarity with standard Python execution (running a .py script from the terminal) versus interactive execution (running cells in Jupyter or IPython).

Execution state and the REPL

The most immediate gap between an experiment and a production system is how state is managed.

A notebook is a Read-Eval-Print Loop (REPL). When you execute a cell, any variables, functions, or classes you define are stored in the memory of the running kernel. Because you can execute cells in any order, the state of the kernel rapidly diverges from the top-to-bottom text written on the screen. You might instantiate a dataframe in cell 1, modify it in cell 5, delete cell 5, and then train a model in cell 2. The model trains successfully in your active memory. If you restart the kernel and run the notebook from top to bottom, it will crash.

Production systems do not have a persistent, interactive kernel. They execute linearly. When a model is loaded into a serving API, it must contain entirely self-sufficient instructions for taking an input and producing an output.

This state mismatch creates severe problems during serialization. When you save a model using Python's pickle or joblib, you are not saving the code that generated the model. You are saving the state of the Python object in memory, along with a reference to the class definition and the module it belongs to.

If you define a custom data transformer class in a notebook cell and use it in your model, Python registers that class under the __main__ module. When you serialize the model and attempt to load it in a separate production script, the unpickler looks for that custom class in the serving script's __main__ module. It will not find it. The model will refuse to load with an AttributeError, even if the underlying logic was mathematically sound. Production requires that all dependencies and custom classes be defined in importable, version-controlled modules, completely decoupled from the execution state of an experiment.

The data reality gap

In a notebook, your data is finite, static, and available all at once. You typically load a CSV or query a data warehouse, resulting in a single, well-typed dataframe.

In production, data is infinite, dynamic, and arrives one record at a time. This fundamental difference in how data is shaped and processed is the primary cause of silent model failure.

Consider categorical encoding. A common notebook pattern is to use pandas.get_dummies() to convert text categories into binary columns. When you pass a dataframe with a color column containing "red", "green", and "blue" to get_dummies(), pandas scans the entire column and creates three new columns. You train your model on this matrix.

In production, a single JSON request arrives: {"color": "red"}. If you convert this to a dataframe and pass it to get_dummies(), pandas only sees "red". It creates a matrix with one column. When you pass this matrix to your model, the model expects three columns. It throws a ValueError and crashes. The notebook approach relied on seeing the entire future distribution of data to format the present data.

This applies equally to numerical scaling. If you call StandardScaler.fit_transform() on your entire dataset before splitting it into training and testing sets, you have committed data leakage. The mean and variance used to scale the training data were calculated using information from the test data. The model appears highly accurate. In production, you cannot call fit_transform() on a single incoming request, because the variance of a single number is zero. You must use the exact mean and variance calculated strictly from the training set.

The gap here is that notebooks encourage global transformations on static datasets. Production requires stateful transformations, where the parameters learned during training (the vocabulary of categories, the mean of a column) are saved and applied blindly to new, unseen data.

Environment and dependency drift

A model is not just a matrix of weights; it is a compiled artifact that sits on top of a deep graph of software dependencies.

When you run an experiment, your environment contains specific versions of Python, scikit-learn, numpy, and underlying C or C++ libraries like BLAS or LAPACK. If you train a model on an Apple Silicon Mac using scikit-learn 1.2, and deploy it to a Linux container running scikit-learn 1.3, you are crossing the environment gap.

Machine learning libraries move fast. Internal class structures, default hyperparameters, and optimization routines change between minor versions. If the production environment has a different version of a library than the training environment, one of two things will happen.

The loud failure is a ModuleNotFoundError or a deserialization error, because an internal class the model relies on was renamed or moved.

The silent failure is mathematical drift. If a library updates its underlying matrix multiplication routine, or changes the default handling of missing values in a transformer, your model will successfully load and predict. However, the exact floating-point outputs will differ from your experiment. Over millions of predictions, this environment-induced drift can cost a business significant revenue, and it is nearly impossible to detect without strict dependency locking.

The notebook hides this because the training and the evaluation happen in the exact same process, on the exact same hardware, at the exact same time. Production separates training and inference by time, space, and operating system.

A worked example

This script demonstrates the data reality gap. It simulates an engineer training a model in a notebook using global pandas transformations, and the subsequent failure when that model processes a single production request. It then demonstrates the correct, production-ready approach using a stateful pipeline.

Save this code as gap_demo.py and run it via python gap_demo.py.

import pandas as pd
import numpy as np
from sklearn.linear_model import LogisticRegression
from sklearn.preprocessing import OneHotEncoder
from sklearn.compose import ColumnTransformer
from sklearn.pipeline import Pipeline

def simulate_notebook_failure():
    print("--- Running Notebook Simulation ---")

    # 1. The static dataset available in the notebook
    train_data = pd.DataFrame({
        'user_type': ['new', 'returning', 'guest', 'new'],
        'time_on_page': [12.5, 45.2, 5.0, 15.1],
        'converted': [0, 1, 0, 0]
    })

    # 2. Global transformation (The Notebook Anti-pattern)
    # get_dummies sees all possible values ('new', 'returning', 'guest') 
    # and creates exactly 3 columns for user_type.
    X_train = pd.get_dummies(train_data[['user_type', 'time_on_page']])
    y_train = train_data['converted']

    # 3. Model training
    model = LogisticRegression()
    model.fit(X_train, y_train)
    print(f"Model trained successfully. Expected features: {model.n_features_in_}")
    print(f"Feature names: {list(X_train.columns)}")

    # 4. Production inference
    # A single user request arrives via an API payload
    api_payload = {'user_type': 'returning', 'time_on_page': 50.5}

    # The serving script attempts to apply the same preprocessing
    prod_df = pd.DataFrame([api_payload])
    X_prod = pd.get_dummies(prod_df)

    print(f"\nProduction data prepared. Features present: {X_prod.shape[1]}")
    print(f"Feature names: {list(X_prod.columns)}")

    # 5. The Crash
    try:
        model.predict(X_prod)
    except ValueError as e:
        print(f"\nCRASH! The gap revealed itself:\n{e}")

def simulate_production_success():
    print("\n--- Running Production-Ready Pipeline ---")

    train_data = pd.DataFrame({
        'user_type': ['new', 'returning', 'guest', 'new'],
        'time_on_page': [12.5, 45.2, 5.0, 15.1],
        'converted': [0, 1, 0, 0]
    })

    X_train = train_data[['user_type', 'time_on_page']]
    y_train = train_data['converted']

    # 1. Stateful Preprocessing
    # We define a transformer that will learn the categories during .fit()
    # and apply them blindly during .transform()
    categorical_transformer = OneHotEncoder(handle_unknown='ignore', sparse_output=False)

    preprocessor = ColumnTransformer(
        transformers=[
            ('cat', categorical_transformer, ['user_type'])
        ],
        remainder='passthrough'
    )

    # 2. The Pipeline encapsulates both stateful preprocessing and the model
    pipeline = Pipeline(steps=[
        ('preprocessor', preprocessor),
        ('classifier', LogisticRegression())
    ])

    # 3. Training
    pipeline.fit(X_train, y_train)
    print("Pipeline trained successfully.")

    # 4. Production inference
    api_payload = {'user_type': 'returning', 'time_on_page': 50.5}
    prod_df = pd.DataFrame([api_payload])

    # 5. The Success
    # The pipeline remembers the 3 categories from training, even though 
    # the production payload only contains 1.
    prediction = pipeline.predict(prod_df)
    print(f"Prediction successful: Class {prediction[0]}")

if __name__ == "__main__":
    simulate_notebook_failure()
    simulate_production_success()

Where people get stuck

Symptom: You load a saved model in your API, pass it data, and receive a ValueError: X has N features, but Model is expecting M features.
The fix: You have a data reality gap. Your training script used a global transformation like pd.get_dummies() or dropped columns dynamically based on missing value thresholds. You must rewrite your training code to use stateful transformers (like scikit-learn's OneHotEncoder) and bundle them with the model using a Pipeline.

Symptom: You attempt to load a .pkl or .joblib model file and receive an AttributeError: Can't get attribute 'MyTransformer' on <module '__main__'>.
The fix: You have an execution state gap. You defined a custom class or function in the same notebook where you trained and saved the model. Move the custom class definition into a separate .py file, import it into your notebook to train the model, and import it into your serving script to load the model.

Symptom: The model runs perfectly in production, but the accuracy is vastly lower than the notebook metrics indicated, even on the first day of deployment.
The fix: You likely committed data leakage during training. Check your notebook to see if you applied scaling, imputation, or text vectorization to the entire dataset before calling train_test_split. If the test set influenced the preprocessing parameters, your offline metrics are a lie. Move all preprocessing inside a pipeline that is fitted strictly on the training split.

Your tasks

Audit for hidden state: Open a machine learning notebook you have written in the past. Select "Restart Kernel and Run All Cells". If it fails, identify which cell relied on hidden state (variables modified out of order or deleted cells). Fix the notebook so it executes linearly from top to bottom.
Eradicate global pandas transformations: Find a script or notebook where you used pd.get_dummies() or df.fillna(df.mean()). Rewrite that section to use sklearn.preprocessing.OneHotEncoder and sklearn.impute.SimpleImputer. Ensure you call .fit_transform() on the training data and only .transform() on the test data.
Simulate the environment gap: Train a simple scikit-learn model in a virtual environment running scikit-learn==1.2.2 and save it as a pickle file. Create a new virtual environment, install scikit-learn==1.3.2, and write a script to load the pickle file and make a prediction. Observe the warnings or errors generated by the version mismatch.

Your tasks this week

Do the exercises above before the next chapter. Reading a tutorial and doing
one are different activities and only one of them changes what you can build.

MLOps: models that survive production

Chapter 1 of 12. New chapter every Thursday night.
Next: Data versioning.

Written by Amit Chakraborty — founding engineer and senior architect: React Native, AI and RAG systems, production architecture. Portfolio · LinkedIn · GitHub.

Need this built, reviewed or taught to your team? Get in touch or email amit@devamit.co.in. Available for senior and founding engineering roles, consulting and training, remote worldwide.

Idempotency as a Product Feature: Run Keys, Leases, and Scheduling

Amit chakraborty — Thu, 10 Sep 2026 16:30:05 +0000

In distributed systems, we often treat idempotency as a defensive implementation detail—a way to prevent database corruption when a network request retries. But after shipping 18 production applications across mobile, web, and desktop, I have come to view idempotency not as a safety net, but as a core product feature.

When building the architecture for Synapsis Medical Technologies, where I served as the first engineering hire, the stakes for "exactly once" execution were not just about data integrity; they were about clinical safety. If a HIPAA-aligned RAG pipeline processing patient vitals or an LLM-driven clinical summary triggers twice, the cost isn't just a duplicate log entry—it is potential medical misinformation or redundant billing.

Over eight years of engineering, I have learned that the "exactly once" delivery problem is fundamentally a scheduling problem. To solve it, we must move beyond simple unique constraints and toward a robust architecture involving run keys and distributed leases.

The Distributed Double-Tap Problem

The core issue is that in a networked environment, "failure" is ambiguous. If a Next.js frontend calls a NestJS API to process a wearable data sync and the request times out, the client has no way of knowing if the request failed to reach the server, failed while processing, or succeeded only for the response to vanish in transit.

Standard retry logic is the enemy here. If the client retries, and the server is not idempotent, you end up with duplicate records. In a HealthTech context, where I managed integrations for FHIR/HL7 and wearables, a duplicate record can break longitudinal patient data.

We often reach for UUID columns with UNIQUE constraints as a first pass. While effective for preventing duplicate rows, they are insufficient for complex workflows where a single request triggers a cascade of side effects—like sending a notification, charging a card, and triggering an LLM inference step. If the process dies halfway through, a simple database constraint won't help you recover the state.

Context: The Shift Toward Durable Execution

The industry is currently moving toward durable execution frameworks, as seen in the recent updates to Temporal and the rise of "serverless" orchestration. The community debate has shifted from "how do we prevent duplicates" to "how do we ensure progress."

In the React Native ecosystem, particularly as we look at the New Architecture’s focus on synchronous communication between JavaScript and Native layers, handling asynchronous side effects becomes even more critical. When I oversaw the architecture from 0 to 1 at Synapsis, we had to ensure that mobile clients—often operating on unstable hospital Wi-Fi—could reliably resume complex uploads without re-triggering expensive AI pipelines.

Architecture: Run Keys and Distributed Leases

To solve this, I implement a two-tier strategy: the Run Key (Idempotency Key) for identification and the Lease for execution control.

1. The Run Key

A Run Key is a client-generated, opaque string that uniquely identifies the intent of an action, not the action itself. Unlike a database ID, which is assigned by the server, the Run Key must be generated as close to the user action as possible.

2. The Lease

A lease is a time-bound lock on a specific Run Key. In the NestJS architectures I’ve designed, we use Redis to manage these leases. When a request arrives with a Run Key, the system attempts to acquire a lease.

If the lease is held, the request is a duplicate currently in progress. The server should return a 409 Conflict or a 202 Accepted with a pointer to the status.
If the lease is expired but the work is marked as "completed" in the persistence layer, the server returns the cached result.
If the lease is available and no work is found, the server begins execution.

The Cost of Implementation: Lessons from the Field

When I scaled the engineering team at Synapsis from zero to 21 engineers in 13 months, one of the biggest challenges was teaching the team to think in terms of "idempotency by default."

We overhauled our CI/CD across five production systems, cutting release cycles from two days down to four hours. A major component of that speed was our ability to deploy with confidence, knowing that if a deployment interrupted a running process, our idempotency logic would allow the system to recover without manual intervention.

However, this comes with a trade-off: storage overhead and state management. You are no longer just storing patient data; you are storing the metadata of the attempt. In our HIPAA-aligned RAG pipeline, which maintained 99.9% uptime, we had to carefully manage the lifecycle of these keys to ensure we weren't bloating our primary databases with millions of expired idempotency tokens.

A Worked Example: The Clinical AI Pipeline

Consider a scenario where a clinician submits a voice note for AI summarization. The pipeline involves:

Transcribing audio (External API).
Mapping to FHIR resources (Internal Logic).
RAG-based clinical summary (LLM Pipeline).

Without a Run Key, a retry at step 3 would re-run steps 1 and 2, wasting money and time.

// A simplified NestJS guard for idempotency
@Injectable()
export class IdempotencyGuard implements CanActivate {
  constructor(private redis: RedisService) {}

  async canActivate(context: ExecutionContext): Promise<boolean> {
    const request = context.switchToHttp().getRequest();
    const key = request.headers['x-idempotency-key'];

    if (!key) return true; // Or enforce it based on policy

    const lock = await this.redis.set(key, 'processing', 'EX', 60, 'NX');
    if (!lock) {
      throw new ConflictException('Request already in progress');
    }

    return true;
  }
}

The real complexity lies in the "recovery" phase. If the LLM pipeline fails, the lease must be released or transitioned to a "failed" state so that the next retry can actually execute, rather than being blocked by a stale lock.

Practical Recommendations

Based on my experience shipping across mobile and web platforms, here are the rules I follow for building idempotent systems:

Client-Side Generation: In React Native, generate the Run Key at the moment the user taps the "Submit" button and persist it to AsyncStorage or SQLite before the network call is even attempted. This ensures that even if the app crashes, the retry uses the same key.
Deterministic Transformations: Ensure your internal logic is deterministic. If you are integrating wearables data, the transformation from raw JSON to FHIR should produce the same output every time for the same input.
Separate Side Effects: Use a transactional outbox pattern. Don't send the HL7 message to the hospital system in the same function that updates your database. Log the intent to send, and let a separate, idempotent worker handle the delivery.
Status Endpoints: Always provide a way for the client to query the status of a Run Key. A GET /status/:runKey endpoint is essential for mobile clients to recover after a hard crash.

Conclusion

Idempotency is not just a technical requirement for distributed systems; it is a product requirement for reliability. Whether you are scaling a team or building a zero-to-one architecture for a high-stakes field like HealthTech, the ability to guarantee that an action happens exactly once—or at least, that its side effects are controlled—is what separates a prototype from a production-grade system.

By treating every request as a scheduled task identified by a Run Key and protected by a lease, you move away from the chaos of "hopeful processing" and toward a system that is resilient by design. The goal is not to prevent failure, but to make failure predictable and recovery automatic.

Systems Engineering for High-Magnitude Seismic Events

Amit chakraborty — Thu, 10 Sep 2026 08:30:02 +0000

The recent magnitude 6.3 earthquake in Alaska, as reported by the USGS, highlights the critical necessity for robust, low-latency distributed systems in seismically active regions. Engineering for these events requires a rigorous focus on telemetry ingestion, edge-based processing, and the maintenance of data integrity across fragmented networks.

Early-Warning Systems and the Latency Budget

In seismic engineering, the "latency budget" is the difference between the arrival of the primary (P) waves and the more destructive secondary (S) waves. For a magnitude 6.3 event, this window is measured in seconds, demanding a system architecture where every millisecond of computational overhead directly reduces the time available for automated mitigation, such as shutting down gas mains or slowing high-speed rail.

The primary constraint is the speed of light versus the speed of seismic waves. While P-waves travel at approximately 5 to 8 kilometers per second, data packets travel at near-light speed. However, the bottleneck is rarely the transmission medium; it is the processing stack. A typical Earthquake Early Warning (EEW) pipeline involves signal detection at the sensor, phase picking, event association, and alert dissemination.

To minimize latency, engineers must move away from traditional request-response cycles. Instead, systems utilize User Datagram Protocol (UDP) or specialized low-overhead protocols to stream raw accelerogram data to regional aggregators. The use of edge computing—performing initial signal analysis at the sensor level to determine if a threshold has been crossed before transmitting—can shave hundreds of milliseconds off the total budget. The goal is a "deterministic latency" profile where the system’s response time is predictable regardless of network load.

Sensor Data Pipelines and Streaming Ingestion

Managing the data from a dense seismic network requires a high-throughput streaming architecture capable of handling massive bursts of telemetry. Under normal conditions, a network of sensors produces a steady, manageable stream of "heartbeat" data. During a magnitude 6.3 event, the volume of data points per second spikes as sensors transition from low-power monitoring to high-frequency sampling.

The ingestion layer must be designed for horizontal scalability and backpressure management. Utilizing distributed streaming platforms like Apache Kafka or Redpanda allows for the decoupling of data producers (the sensors) from consumers (the analysis engines). This decoupling ensures that even if the analysis engine is momentarily saturated, the incoming seismic data is buffered and not lost.

Data integrity in these pipelines is maintained through schema registries and time-series optimization. Because seismic data is inherently chronological, using a time-series database (TSDB) for the persistence layer allows for rapid querying of historical waveforms against real-time data. Engineers must also account for "clock drift" across thousands of remote sensors; Network Time Protocol (NTP) or GPS-synchronized clocks are mandatory to ensure that event association algorithms are processing data from the same temporal window.

Store-and-Forward and Mesh Networking

A significant failure mode in high-magnitude events is the loss of backhaul connectivity. When fiber optics are severed or cellular towers lose power, the engineering challenge shifts from real-time streaming to resilient data persistence and alternative routing.

Store-and-forward architectures are essential for remote stations. If the primary uplink fails, the sensor node must have sufficient local storage (often industrial-grade SD cards or eMMC) to buffer high-resolution data for days or weeks. Once connectivity is restored, the system must implement a "catch-up" mechanism that prioritizes real-time data while trickling in the buffered historical data in the background to prevent overwhelming the restored link.

In environments where traditional infrastructure is unreliable, mesh networking provides a redundant path for critical alerts. By utilizing sub-gigahertz radio frequencies (such as LoRaWAN or specialized RF mesh protocols), sensors can hop data through neighboring nodes to reach a functional gateway. The trade-off here is bandwidth; mesh networks cannot typically support high-definition waveform streaming, so the system must be capable of "graceful degradation"—switching from full telemetry to sending only basic metadata (peak ground acceleration and event duration) when bandwidth is constrained.

Offline-First Applications for Field Operations

For systems designed to be used by responders in the aftermath of a magnitude 6.3 event, the "online" state must be treated as a luxury, not a requirement. An offline-first architecture ensures that applications remain functional despite a total lack of internet connectivity.

This is achieved through local-state synchronization. Rather than relying on a central API for every action, the application operates against a local database (such as SQLite or Realm) residing on the device. When a network connection is detected, the system performs a multi-way sync to reconcile local changes with the global state.

Conflict resolution is the primary engineering hurdle in these systems. If two responders update the status of a specific infrastructure component simultaneously while offline, the system must use Conflict-free Replicated Data Types (CRDTs) or last-write-wins logic to ensure eventual consistency across the entire distributed system. Furthermore, map data and critical SOP (Standard Operating Procedure) documents must be pre-cached on the device, as high-latency satellite links are often insufficient for downloading large assets during an active recovery phase.

Critical Implementation Requirements

A team building a seismic resilience system must prioritize three core technical pillars:

Hardware Watchdogs: Remote sensors must be capable of self-healing. If the software stack hangs due to a memory leak or an unhandled exception during an event, hardware watchdog timers must trigger a hard reset to bring the node back online without manual intervention.
Power Autonomy: Systems must be designed for ultra-low power consumption, utilizing solar arrays and deep-cycle battery backups. The power management system should be integrated into the telemetry stream, providing early warnings of battery degradation before a failure occurs.
Simulation and Stress Testing: The only way to validate a magnitude 6.3 response is through rigorous "Chaos Engineering." Teams must simulate network partitions, high-latency links, and massive data spikes in a staging environment to ensure the ingestion pipeline and alerting logic do not collapse under the exact conditions they were built to monitor.

The engineering of these systems is a balance between the physics of the earth and the constraints of digital infrastructure. Success is defined by the system's ability to remain deterministic and functional when the physical environment is at its most volatile.

This piece is about the engineering, not the event. For what actually happened and for anything anyone affected needs to act on, go to the source: USGS. Emergency guidance comes from your local emergency service and from nobody else.

Written by Amit Chakraborty — founding engineer and senior architect: React Native, AI and RAG systems, production architecture. Portfolio · LinkedIn · GitHub. Building systems that have to work when things are going wrong is most of what this is — get in touch or email amit@devamit.co.in.

Architecture Over Algorithms: Scaling an Engineering Team from 0 to 21

Amit chakraborty — Thu, 10 Sep 2026 04:30:02 +0000

When I joined Synapsis Medical Technologies as the founding engineer, the roadmap was daunting: we needed to build a HealthTech AI platform that integrated wearable data, handled FHIR/HL7 standards, and maintained a HIPAA-aligned RAG pipeline with 99.9% uptime. To execute this, I had to scale the engineering team from 0 to 21 engineers in just 13 months.

The standard industry approach to hiring—grinding candidates through LeetCode puzzles and red-black tree inversions—was never an option. We weren't building a search engine; we were building a complex, regulated ecosystem across React Native, Next.js, and NestJS. I needed architects who understood state synchronization and data integrity, not just competitive programmers. Over 8 years of professional engineering and 18 production applications, I have found that the ability to solve an algorithm puzzle rarely correlates with the ability to ship a resilient production system.

The Problem: The High Cost of the Wrong Signal

In the early days of a startup, a single hiring mistake is a catastrophic drag. If you hire an engineer based on their ability to optimize a sorting algorithm, you might end up with someone who builds a "perfect" technical solution that fails to account for the constraints of a HIPAA-compliant environment or the latency requirements of a clinical AI.

At Synapsis, our stack was multifaceted. We were managing five production systems simultaneously. Our CI/CD overhaul, which eventually cut release cycles from 2 days down to 4 hours, required engineers who understood the "plumbing" of a system—how code moves from a local environment to a regulated cloud. An algorithm-heavy interview loop ignores these competencies. It fails to test for:

Systemic Thinking: How does a change in the NestJS backend affect the React Native mobile client’s offline storage?
Regulatory Awareness: How do we handle PII (Personally Identifiable Information) within a RAG pipeline without sacrificing performance?
Maintainability: Can this engineer write code that the next 20 hires can understand and extend?

Context: The Shift Toward Practical Assessment

The broader industry is currently navigating a shift in how technical talent is evaluated. With the release of React Native 0.76 and its move toward the New Architecture (New Arch) by default, the barrier for entry has moved from "can you write a UI?" to "do you understand the bridge and the JSI?" Similarly, the rise of LLM-integrated applications has changed the definition of a "Full-Stack" engineer.

In the current climate, where AI can solve most algorithmic puzzles in seconds, the value of an engineer lies in their architectural judgment. The community is increasingly debating the utility of "whiteboard coding" when tools like GitHub Copilot have made syntax trivial. My goal was to design a loop that bypassed what a machine can do and focused on what only a senior architect can do: manage complexity and trade-offs.

The Technical Explanation: Designing for "System Fluency"

To scale to 21 engineers, I designed a hiring loop centered on what I call "System Fluency." This replaced the traditional 45-minute coding challenge with a three-stage architectural evaluation.

Stage 1: The Practical Debugging Exercise

Instead of a blank canvas, we gave candidates a broken version of a simplified NestJS/Next.js environment. The bugs were not syntax errors; they were architectural flaws—a race condition in a database transaction or a memory leak in a React hook. This tested their ability to navigate an existing codebase, which is 90% of the job.

Stage 2: The Distributed Systems Deep-Dive

For senior roles, we focused on the RAG and LLM pipelines. I looked for engineers who could explain how to maintain 99.9% uptime for a clinical AI. We would discuss the trade-offs between vector database providers, the nuances of chunking strategies for medical documents, and how to implement FHIR/HL7 integrations without creating a bottleneck.

Stage 3: The "Day Two" Discussion

We asked candidates to evolve a system. "We've built the MVP; now we need to integrate wearable data from 10,000 concurrent users. Where does the architecture break?" This revealed whether they understood the lifecycle of a production application or if they were only focused on the "0 to 1" phase.

Architecture and Trade-offs

When I owned the React Native, Next.js, and NestJS architecture at Synapsis, every decision was a trade-off. Choosing NestJS for the backend provided a structured, Angular-inspired framework that made it easier to onboard new engineers as we scaled. However, it added a layer of abstraction that required a specific mental model.

Our hiring loop had to reflect these specific architectural choices. If a candidate was a "purist" who hated opinionated frameworks, they would struggle in our NestJS environment. If they didn't understand why we used Next.js for our web presence while maintaining a separate React Native codebase for mobile, they wouldn't be able to contribute to our cross-platform strategy.

The trade-off in our hiring process was speed. It takes longer to evaluate a candidate's architectural thinking than it does to grade a coding test. However, the "cost per hire" was significantly lower in the long run because our retention was high and our technical debt remained manageable even as we tripled the team size.

A Worked Example: The Wearables Integration

To illustrate how this hiring philosophy translated to production, consider our wearables integration. We needed to ingest high-frequency data from devices and feed it into our AI pipelines while remaining HIPAA-compliant.

In an interview, I wouldn't ask a candidate to write a function that filters an array of heart rate data. Instead, I would ask: "How do you design a system that ingests heart rate data from an Apple Watch, stores it in a HIPAA-compliant manner, and triggers an LLM-based clinical alert if a threshold is met?"

A successful candidate would discuss:

Ingestion: Using a message queue (like RabbitMQ or BullMQ) to decouple the ingestion from the processing.
Security: Encrypting data at rest and in transit, ensuring the LLM provider is covered by a Business Associate Agreement (BAA).
Concurrency: Handling the surge of data when thousands of devices sync simultaneously.

This is the exact work we did to maintain our 99.9% uptime. By hiring for these specific scenarios, we ensured that every new engineer was ready to contribute to our five production systems on day one.

What it Cost to Learn

Scaling a team this quickly taught me that the "Founding Engineer" role is as much about culture as it is about code. I learned that you cannot outsource the "vibe check" of technical excellence. In the first few months, I personally interviewed every candidate.

I also learned that transparency in the CI/CD process is a massive recruiting tool. When I told candidates we had cut our release cycles from 2 days to 4 hours, the best engineers wanted to know how. They were attracted to a culture that valued developer velocity and automated testing. The "cost" of building this culture was an immense upfront investment in infrastructure—specifically, building out the automated pipelines for our React Native and NestJS services—but it was the only way to support a 21-person team without descending into "merge-conflict hell."

Practical Recommendations

For engineering leaders looking to scale a team without relying on algorithm puzzles, I recommend the following:

Audit Your Stack for "Friction Points": Identify the most complex parts of your architecture (for us, it was the FHIR integrations and RAG pipelines). Build your interview questions specifically around these points.
Prioritize System Design Over Syntax: If an engineer can explain the difference between a relational database and a vector store in the context of your product, they can learn your specific ORM in a week.
Test for "Production Empathy": Ask candidates about the worst bug they ever shipped to production. Their answer will tell you more about their sense of responsibility and debugging methodology than any whiteboard exercise.
Invest in CI/CD Early: You cannot scale a team to 20+ people if your release cycle is measured in days. Automation is the prerequisite for team growth.

Conclusion

Building the engineering foundation at Synapsis Medical Technologies required more than just technical skill; it required a hiring strategy that prioritized architectural vision over rote memorization. By focusing on how engineers interact with complex systems—from HIPAA-aligned AI pipelines to cross-platform mobile architectures—we were able to grow from a solo founder's vision to a robust team of 21 in just over a year. The 18 production applications I have shipped over the last 8 years have taught me one thing: the architecture you build is only as good as the team you hire to maintain it. Focus on the system, and the code will follow.