DEV Community: Rahman Nugar

Designing a Multi-Tenant Storefront With Wildcard Subdomains

Rahman Nugar — Sat, 11 Jul 2026 18:39:59 +0000

At my workplace, I worked on an ERP platform used by fashion businesses to manage customers, body measurements, products, orders, invoices, inventory, staff, and other day-to-day operations. Each business also had a public storefront where customers could browse products and check out.

The storefront started as a simple sharing feature. Businesses could publish products, copy a link, and send it to customers outside the main workspace. That worked well because the storefront was mostly a product catalogue, and most of the sales process still happened after the customer contacted the business.

As the platform evolved, the storefront became much more than a catalogue. Customers were discovering businesses through shared links, browsing products, placing an order, and tracking orders directly from the storefront. That introduced new technical requirements around branded storefronts, SEO, server-rendered metadata, public checkout, pricing, and analytics.

This article explores how I designed the storefront around wildcard subdomains, immutable shop identities, server-side shop resolution, and a scalable analytics pipeline.

Giving the Storefront Its Own Identity
Business Names, Reserved Names, and Subdomains
Resolving a Storefront
Active and Inactive Storefronts
Location and Currency
Product Pages and Share Previews
Storefront Event Ingestion
Processing Raw Events
Counting Unique Visitors With HyperLogLog
Domain Routing and Local DNS

1. Giving the Storefront Its Own Identity

The original storefront was fairly simple. It was a React application that fetched a business and rendered its products. Beyond that, there wasn't much to it. There were no branded storefronts, analytics, subdomains, or even a separate identity beyond the business itself.

Supporting those capabilities meant the storefront needed its own data model. I introduced a dedicated shop entity to represent the public storefront.

The business remained the source of operational data such as customers, products, orders, subscriptions, staff, and settings. The shop entity became the source of everything related to the public-facing storefront.

shops
  id
  businessId
  slug
  subdomain
  status
  inactiveReason
  createdAt
  updatedAt

businessId, slug, and subdomain are all unique. This gives every storefront a stable internal identity, a human-readable public address, and an immutable fallback slug that continues to identify the storefront even if the business name or subdomain changes.

To support existing businesses, I backfilled the new table by generating an immutable slug and deriving a subdomain from each business name. If a derived subdomain was reserved or already in use, the migration failed instead of generating an alternative automatically. Since the business name determines the public storefront address, changing it behind the user's back would make the storefront feel unpredictable.

2. Business Names, Reserved Names, and Subdomains

Every storefront has two public addresses:

abdulrahmon.cuttoshape.com
abdulrahmon.cuttoshape.com/products/:productId

cuttoshape.com/shop/:slug
cuttoshape.com/shop/:slug/products/:productId

The subdomain is the primary storefront address that customers can easily remember and share. The slug is a permanent fallback.

Rather than asking businesses to choose a separate storefront name, the subdomain is derived from the business name. When a business is created or renamed, the name is normalized by converting it to lowercase, removing unsupported characters, replacing spaces with hyphens, collapsing repeated separators, and ensuring it fits within DNS label limits.

For example:

Adenuga Marts -> adenuga-marts

Since the business name determines the public storefront address, the same request also validates the platform's subdomain policy. Derived subdomains cannot conflict with existing storefronts or use reserved platform names such as api, admin, www, docs, or other names the platform may need in the future.

If validation fails, the business name update is rejected. The system does not generate alternatives such as adenuga-marts-2 because silently changing a business's public identity would make storefront URLs unpredictable.

The fallback slug serves a different purpose. It is generated by the backend, immutable, and never exposed for editing.

cuttoshape.com/shop/7Kxq9BvL2pQ8mNz4RcT6yWaDk9Lp2Qs8Vn3Tx5Zr

It isn't meant to be memorable but to permanently identify the storefront, even if the business name changes or the custom subdomain becomes unavailable.

3. Resolving a Storefront

Every public storefront request begins by resolving the incoming address to a storefront.

For subdomain requests, the storefront application extracts the tenant label from the request host and asks the backend to resolve it.

GET /api/public/storefronts/resolve?subdomain=adenuga-marts

For fallback URLs, the backend resolves the storefront by its immutable slug.

GET /api/public/storefronts/slug/:slug

Once resolved, every public operation works with the storefront's internal identifier. Products, checkout, and analytics no longer care whether the request came from a subdomain or a slug.

The backend also returns the storefront's canonical public URL. If the storefront's subdomain is active, the canonical URL is the subdomain. Otherwise, it is the slug-based URL. Clients simply use the returned value when generating links instead of rebuilding URLs from business names or environment-specific rules.

4. Active and Inactive Storefronts

A storefront that doesn't exist isn't the same as one that's unavailable, so I kept the model simple.

status: active | inactive
inactiveReason: string | null

If the storefront doesn't exist, the resolver returns a normal 404.

If it exists but is inactive, the storefront still resolves, but browsing and checkout are blocked. This lets the frontend show a proper unavailable page instead of treating it as a missing storefront.

The inactive reason is just a string. That makes it easy to introduce new reasons without updating every client.

5. Location and Currency

The storefront serves customers from different countries, so it couldn't display the same currency to everyone.

The product supported three markets:

Nigeria         -> NGN
United Kingdom  -> GBP
Everywhere else -> USD

I resolved the visitor's market from their request IP and cached the result for one day to reduce requests to the geolocation provider. If the location couldn't be determined, the storefront used the currency specified in the URL. If that wasn't present either, it fell back to the business's primary currency.

The resolved currency was then used throughout the storefront. Products already supported multiple currencies, including fabric-specific pricing, so customers saw prices that matched their market without requiring separate storefronts.

6. Product Pages and Share Previews

The original storefront lived inside the multi-tenant React dashboard. That worked well until product pages needed server-generated metadata for SEO and link previews.

The first approach was a server-rendered endpoint that generated the metadata and redirected customers back to the React storefront. It solved the metadata problem, but the public storefront URL still wasn't responsible for rendering the page.

I eventually split the public storefront from the dashboard into its own Next.js application. Storefronts and product pages now resolve their data, generate metadata, and render HTML from the same URL.

7. Storefront Event Ingestion

As the storefront grew, both businesses and the platform needed visibility into how storefronts were performing.

The storefront emits a small set of analytics events.

shop_view
product_view
product_search
add_to_cart
checkout_started
checkout_submitted

Analytics events are submitted asynchronously. If event collection fails, customers can still browse products, add items to their cart, and check out normally.

Not every event is captured the same way. Impression events such as shop_view and product_view are sent after a page has rendered, while interaction events such as add_to_cart, checkout_started, and checkout_submitted are sent directly from user actions. Search events are only recorded after the search has settled rather than on every keystroke.

Each event contains enough information for downstream processing.

{
  "shopId": "shop_123",
  "businessId": "business_123",
  "productId": "product_456",
  "eventType": "product_view",
  "visitorId": "visitor_abc",
  "sessionId": "session_xyz",
  "clientEventId": "event_789",
  "currency": "NGN",
  "clientTimestamp": "2026-07-11T14:20:00Z"
}

The clientEventId uniquely identifies an analytics event. The backend enforces a unique constraint on (shopId, clientEventId), making retries safe without counting the same event twice.

8. Processing Raw Events

The backend doesn't update analytics counters directly from the public request.

Instead, every accepted event is stored as a raw event and queued for background processing.

                 Return 202
                      ▲
                      │
Storefront ──► Store raw event
                      │
                      ▼
                   Queue
                      │
                      ▼
              Analytics worker

A raw event represents a single analytics event before aggregation.

storefront_events

shopId
businessId
productId
eventType
visitorId
sessionId
clientEventId
currency
clientTimestamp
processedAt

When an event is first stored, processedAt is null. After the worker successfully processes it, processedAt is updated. This allows the worker to safely retry failed jobs without processing the same event twice.

The worker aggregates raw events into daily analytics tables for storefronts, products, and searches. These rollups power the analytics dashboard, while the raw events are retained for 90 days before a scheduled cleanup job removes processed records.

9. Counting Unique Visitors With HyperLogLog

Page views alone weren't enough because businesses also wanted to know how many unique visitors were reaching their storefronts.

Calculating distinct visitors from the raw events becomes more expensive as traffic grows because every visitor identifier has to be stored and queried.

I used Redis HyperLogLog for this part of the pipeline. Rather than storing every visitor identifier, HyperLogLog hashes each identifier and keeps only enough information to estimate how many unique values have been seen. The estimate isn't exact, but memory usage remains almost constant regardless of whether a storefront receives hundreds or millions of visitors.

As the analytics worker processes each event, it identifies the visitor using the persistent visitorId, falling back to the sessionId or request IP when necessary, and updates the daily HyperLogLog key for that storefront. Retrying the same event is safe because adding the same identifier again doesn't change the estimate.

The dashboard combines exact event totals from the SQL rollup tables with estimated unique visitor counts from HyperLogLog. Daily HyperLogLog keys can also be merged, allowing Redis to estimate distinct visitors across a selected period without counting returning visitors more than once.

Storefront analytics is intentionally limited to predefined reporting periods of up to one year. HyperLogLog keys are retained for 400 days, giving one-year reports a small retention buffer while preventing Redis memory from growing without bounds.

10. Domain Routing and Local DNS

The production setup uses a wildcard DNS record so any valid business subdomain resolves to the public storefront application.

*.cuttoshape.com
        ↓
Public storefront app

The application extracts the subdomain from the request host, resolves the corresponding storefront, and renders the page.

Slug routes follow a different path.

cuttoshape.com/shop/:slug

Instead of extracting a subdomain, the application resolves the storefront directly from its immutable slug before rendering the page.

I also wanted local development to behave like production, so I used dnsmasq to configure wildcard local DNS instead of relying on localhost.

address=/cuttoshape.local/127.0.0.1

That allowed me to test requests such as:

adenuga.cuttoshape.local
anything.cuttoshape.local

locally before deploying the wildcard DNS configuration.

How Applications Stay Available During Deployment

Rahman Nugar — Fri, 26 Jun 2026 12:30:41 +0000

You just built your application and you're preparing to deploy it. Then you ask the question:

What happens to my application and its clients and services when I make changes and deploy?

If you're building a side project with only a few users, it's easy to simply redeploy and not bother too much about what happens during deployment.

However, as your application grows, deployment itself becomes an important part of software engineering. Clients and services continue interacting with your application while you're replacing it with a newer version, so how do modern applications continue serving requests without going offline?

There are four common deployment strategies, each approaching this problem differently.

Restart / Recreate
Rolling Deployment
Canary Deployment
Blue-Green Deployment
Choosing the Right Deployment Strategy
Deployment Isn't Just About Code

1. Restart / Recreate

Restart (also known as Recreate) is the simplest deployment strategy.

In this method, deploying a new version of your application simply turns off the current version and starts the newer one. It's simple, easy to understand, and requires very little infrastructure.

The downside is that it introduces a temporary blackout. While the old version has stopped and the newer version is still starting, clients and services are unable to communicate with your application.

Rollback also isn't immediate. If something goes wrong after deployment, you need to redeploy the previous version, introducing another period of downtime.

This deployment strategy is rarely used for customer-facing production applications because of the downtime it introduces, but it's perfectly reasonable for personal projects, internal tools, or applications where a brief outage is acceptable.

2. Rolling Deployment

Rolling deployment approaches the problem differently.

Instead of replacing every running instance at once, you gradually replace instances of the older version with newer ones. As each new instance starts, health checks validate that it is healthy before traffic is routed to it. This process continues until every running instance has been replaced.

Unlike the restart strategy, clients and services can continue communicating with your application throughout the deployment. Rolling deployment is also the default deployment strategy in Kubernetes (K8s).

One important caveat is that rolling deployments generally require two or more running instances of your application. If you only have a single instance, there is nowhere for traffic to go while that instance is being replaced, making it effectively a restart deployment.

Rolling deployments also introduce a new challenge.

During deployment, two versions of your application coexist. Requests are routed to different instances through a load balancer, meaning clients and services may communicate with either the older or newer version at the same time.

This means both versions must remain compatible throughout the deployment. If the newer version no longer understands requests, shared data, or contracts produced by the older version, parts of the system can begin failing even though the deployment itself is progressing successfully.

Rolling deployments also make rollbacks more involved. Since the older version is being gradually replaced, a rollback usually means performing another rolling deployment back to the previous version rather than instantly switching traffic to a fully preserved environment.

Rolling deployment is one of the most widely used deployment strategies because it provides zero downtime without requiring two complete environments. The tradeoff is that both versions of your application temporarily coexist, making backward compatibility an important part of the deployment process.

3. Canary Deployment

Canary deployment approaches the problem differently.

Instead of gradually replacing every running instance equally, it changes how traffic is routed during deployment.

Only a small percentage of clients and services are routed to the newer version while the majority continue communicating with the older version.

For example:

95% → Older version
5% → Newer version

The newer version is continuously monitored using health checks and production metrics. If everything looks healthy, more traffic is gradually shifted to the newer version until it eventually serves all requests.

The idea is to limit the number of clients and services exposed to a new version until its stability and correctness have been validated.

Like rolling deployments, both versions of the application coexist during deployment. This means the same compatibility concerns still apply. If the newer version no longer understands requests, shared data, or contracts expected by the older version, parts of the system can begin failing even though only a small percentage of traffic has been routed to it.

One advantage of canary deployment is that if a problem is detected early, traffic can simply stop being routed to the newer version while the issue is investigated. Since only a small percentage of clients and services were exposed to the new version, the impact of a bad release is significantly reduced.

Canary deployments are commonly used when reducing the impact of a bad release is more important than deploying every client to the newer version immediately.

4. Blue-Green Deployment

Blue-Green deployment approaches the problem differently.

Instead of gradually replacing instances or gradually shifting traffic, an entirely new environment is deployed alongside the current one.

Initially, all traffic continues flowing to the Blue environment while the Green environment is deployed and validated using health checks.

Once the Green environment has been validated, traffic is switched from Blue to Green.

This gives us zero downtime throughout the deployment process. It also provides one of the simplest rollback strategies. If something goes wrong after deployment, traffic can simply be routed back to the Blue environment while the issue is investigated.

The tradeoff is infrastructure cost. Since both environments are running at the same time, you're effectively running two versions of your application during deployment.

Blue-Green deployment is commonly used for applications where zero downtime and rapid rollback are important requirements.

5. Choosing the Right Deployment Strategy

There isn't a perfect deployment strategy. Each one comes with its own tradeoffs.

Restart deployment optimizes for simplicity.

Rolling deployment optimizes for resource efficiency while allowing clients and services to continue communicating with the application during deployment.

Canary deployment optimizes for reducing the impact of bad releases by limiting the number of clients and services exposed to newer versions.

Blue-Green deployment optimizes for zero downtime and provides one of the simplest rollback strategies at the cost of running two environments during deployment.

Personally, I tend to use Restart deployments for personal projects and Rolling or Canary deployments for applications with active clients and services. The right deployment strategy ultimately depends on the availability requirements, risk tolerance, and infrastructure of your application.

6. Deployment Isn't Just About Code

One thing that's easy to overlook is that deployments don't only change application code. They often change data too.

Rolling back code is usually straightforward. Rolling back database changes can be significantly harder, and in some cases, nearly impossible.

Imagine you're deploying a new version of your application that replaces a full_name column with a name column.

If the older column is removed before every application instance has been updated, older versions of the application may begin failing because they still expect full_name to exist.

This becomes especially important during Rolling and Canary deployments where multiple versions of the application are communicating with the same database at the same time. Even Blue-Green deployments are not immune to this. Routing traffic back to the older environment does not automatically restore database changes that have already been applied.

One common approach is the expand-and-contract pattern.

First, expand the schema by introducing the new structure while keeping the existing one.

Next, deploy application code that remains compatible with both versions and backfill older data where necessary.

Once every application instance is running the newer version, the older schema or contract can safely be removed.

How Data Access Breaks Down Under Load

Rahman Nugar — Wed, 13 May 2026 15:27:18 +0000

Most database performance problems do not begin with obviously slow queries.

In fact, many systems look perfectly fine early on. Queries execute quickly, endpoints respond in a few milliseconds, and the database appears healthy. Even when something starts slowing down, the fix usually feels simple enough. Add an index, reduce a join, cache a response, and move on.

That works for a while, which is part of what makes these issues deceptive.

Because in production systems, performance problems rarely come from a single query being expensive in isolation. More often, they emerge from how the application accesses data as traffic increases and concurrency grows.

A request that looks harmless locally may execute dozens of queries. Some of those queries may repeat unnecessarily. Some may fetch significantly more data than is actually needed. Others may hold connections longer than expected or compete with other transactions under load. None of these things look particularly dangerous on their own, but once they begin happening across hundreds or thousands of requests, the behavior of the system changes completely.

The Real Problem
Profiling Data Access Properly
N+1 Query Problem
Overfetching and Data Shape
Indexes
Connection Pools and Throughput
Transactions, Isolation, and Contention
Deadlocks
How These Problems Compound
Closing Thoughts

1. The Real Problem

A database does not receive queries in isolation. It receives a continuous stream of queries generated by application code, and that stream is shaped entirely by how requests are implemented.

As engineers, we often think in terms of individual operations:

fetch user
fetch orders
fetch comments

But the database does not see isolated operations. It sees concurrent requests, connection pressure, transaction overlap, repeated scans, lock contention between related requests, and large volumes of queries arriving continuously from the application layer.

This is why systems that feel “fast” in development can degrade surprisingly quickly in production.

Locally, you might test with:

20 users
small datasets
almost no concurrency

Production changes all of those assumptions simultaneously. The dataset becomes larger. More requests execute at the same time. Queries that looked harmless start repeating at scale. Operations that used to take milliseconds begin waiting on locks or connections instead of execution itself.

2. Profiling Data Access

Most engineers start profiling from the database. They look for slow queries, run EXPLAIN ANALYZE, and try to optimize whatever looks expensive.

That approach is incomplete, because it assumes the problem is within a single query. A query that takes 300ms once may not be a real problem. A query that takes 3ms but executes 200 times per request usually is.

In reality, you need to start from the request.

Take an endpoint and break it down in terms of what it actually does to the database. Not just the result it returns, but the work it generates.

For example:

GET /dashboard

query_count: 74
total_db_time: 118ms
max_query_time: 6ms

Nothing there looks especially alarming until you realize the endpoint executes seventy-four queries.

At low traffic, that may still feel fast enough. Under concurrency, it becomes a completely different problem because every request now generates far more database work than expected.

Repetition Is Often Worse Than Latency

A very common production issue is not necessarily slow queries, but repeated queries.

Something like:

sql
SELECT * FROM posts WHERE user_id = ?

executed over and over again within the same request can lead to N + 1 query problem.

Execution Time Is Not the Full Cost

Another thing that becomes important under load is separating execution time from wait time.

A query might execute quickly once it reaches the database, but still spend significant time:

waiting for a connection
waiting on another transaction
waiting for locks to clear When EXPLAIN Actually Helps

EXPLAIN ANALYZE becomes useful once you confirm the issue is inside the query itself.

For example, if a query unexpectedly performs a sequential scan over a very large table:

Seq Scan on sessions
Rows Removed by Filter: 900000

that is usually a strong signal that:

an index is missing
the existing index is unusable
or the query shape does not match the access pattern properly

But EXPLAIN only helps with localized inefficiency. It does not tell you whether the application is generating too many queries overall, saturating the connection pool, or overfetching aggressively.

3. N+1 Query Problem

The N+1 problem is one of the easiest ways to accidentally overload a database without realizing it early enough.

The reason it slips through so often is because the code usually looks somewhat reasonable.

ts
const users = await prisma.user.findMany()

for (const user of users) {
  const posts = await prisma.post.findMany({
    where: {
      userId: user.id
    }
  })
}

Nothing about this feels obviously dangerous during development.

If there are 10 users, this endpoint executes:

1 query to fetch users
10 additional queries to fetch posts

The issue is not that the queries are individually slow. The issue is that the amount of database work now scales with the number of records returned.

As the dataset grows:

100 users → 101 queries
500 users → 501 queries

The endpoint becomes progressively more expensive simply because more rows are returned.

Under concurrency, this gets worse very quickly because every request repeats the same inefficient access pattern against the database.

One common mistake is assuming that concurrency fixes the problem.

For example:

ts
await Promise.all(
  users.map((user) =>
    prisma.post.findMany({
      where: {
        userId: user.id
      }
    })
  )
)

This may reduce the response time of the endpoint because the queries now execute concurrently, but the application is still generating one query per user.

The access pattern itself has not changed.

In some cases, this can actually make things worse because the application now sends many related queries to the database at the same time instead of sequentially. Under enough traffic, that creates even more connection pressure and query contention.

The proper fix is usually to fetch related data via joins or batch queries.

For example:

const users = await prisma.user.findMany({
  include: {
    posts: true
  }
})

const userIds = users.map((user) => user.id)

const posts = await prisma.post.findMany({
  where: {
    userId: {
      in: userIds
    }
  }
})

4. Overfetching and Data Shape

In many systems, the problem is not necessarily that queries are slow. The problem is that queries return significantly more data than the request actually needs.

For example:

selecting entire rows instead of specific fields
loading large relations unnecessarily
returning deeply nested objects to clients that only need summaries

ORMs make this particularly easy because queries are abstracted with language code.

Something like:

include: {
  posts: true
}

might technically solve an N+1 problem while still introducing unnecessary work elsewhere.

Maybe the client only needs:

post title
createdAt
latest 5 posts

but the query now returns:

full post bodies
metadata
all historical posts
nested relations

At low traffic, this usually feels harmless however under load, it becomes expensive because every unnecessary field now contributes to:

larger payloads
higher memory usage
longer serialization time
increased network transfer
more cache pressure

5. Indexes and Access Patterns

A lot of engineers think of indexes as generic speed improvements, but indexes are really about access patterns. They determine how efficiently the database can locate data as datasets grow. Without an index, the database often has no efficient way to locate matching rows, so it scans through the table looking for them.

With an index, the database can navigate directly to the relevant portion of data instead of traversing everything.

Imagine an order table with 1000 rows, scanning the entire DB to return orders for a user may feel fast here however such query may become extremely expensive at 10 million rows even though the query itself never changed.

Composite Indexes

Composite indexes become important once queries filter or sort across multiple fields.

For example:

@@index([userId, revoked])

works well for queries like:

WHERE userId = ?
AND revoked = false

One thing to note about composite indexes is that they are order-sensitive.

@@index([userId, revoked])

would work for queries like:

WHERE userId = ?
AND revoked = false

WHERE userId = ?

but not

 WHERE revoked = false and userId = ?

Indexes Are Not Free

Indexes improve reads by introducing additional work elsewhere.

Every insert, update, or delete must now maintain those index structures as well.

Too many indexes can:

slow writes
increase storage usage
increase memory pressure
create unnecessary maintenance overhead

The correct pattern is to think in terms of tradeoffs, you ideally want to index read heavy table columns.

6. Connection Pools and Throughput

Every query requires a database connection to fetch data or mutate state. These connections are not lightweight resources. They consume:

memory
CPU scheduling overhead
active database resources

Without pooling, applications can overwhelm the database very quickly under concurrency. Instead of opening a new connection per request the application maintains a reusable pool of active connections shared across requests.

At that point, the system effectively becomes a queue:

requests wait for available connections
queries execute
connections return to the pool

Pool Saturation

Once all connections are busy:

new queries must wait
request latency increases
timeouts begin appearing

This is one reason systems sometimes feel slow even when individual queries are relatively fast.

The queries themselves may execute quickly once they reach the database, but they spend significant time waiting for available connections beforehand.

Pool Size Trade-offs

A pool that is too small increases queueing and latency meanwhile pool too large creates a different problem.

Too many concurrent connections increase:

context switching
lock contention
database scheduling overhead

Eventually the database spends more time coordinating active work than executing queries efficiently.

This is also why tools like PgBouncer become important in high concurrency systems. They reduce connection overhead and help applications manage large numbers of requests more efficiently.

Pooling, however, does not fix inefficient access patterns. It only controls how much concurrent pressure reaches the database at once.

A badly optimized endpoint behind a connection pool is still a badly optimized endpoint. The pool simply delays the point at which the system begins struggling.

This distinction becomes important because many performance issues that appear to be “database problems” are actually workload problems created by the application layer itself.

7. Transactions, Isolation, and Contention

Transactions refer to set of operations that fail or succeed together. Relational databases utilizes transactions(if configured) to carry out DB work. They ensure atomicity but alone do not automatically guarantee correctness under concurrency.

Once systems start handling large amounts of concurrent traffic, correctness becomes just as important as performance.

Multiple requests may now attempt to:

update the same rows
read partially changing data
modify shared resources simultaneously

Without proper transaction control, this can create subtle inconsistencies that are extremely difficult to debug once they appear in production.

Isolation

Isolation levels determine how transactions behave while other transactions are executing at the same time.

For example:

can one transaction read uncommitted changes from another?
can the same query return different results within the same transaction?
can two transactions overwrite each other’s updates?

These problems become more visible once systems become highly concurrent.

One common example is the lost update problem.

Imagine two concurrent requests reading the same balance:

Balance = 100

Transaction A reads 100
Transaction B reads 100

Transaction A updates to 50
Transaction B updates to 50

The final balance becomes 50 instead of 0 because both transactions operated on stale state.

This is why isolation levels exist.

Lower isolation levels improve throughput because transactions coordinate less aggressively, but they also allow more concurrency anomalies.

Higher isolation levels improve correctness, but increase coordination overhead and reduce concurrency; meaning concurrent requests run similarly to a one after another flow.

For example:

analytics systems may tolerate slightly stale reads
payment systems usually cannot

One thing that becomes important under heavy traffic is understanding that transactions also hold resources while they remain open.

Long-running transactions increase:

lock duration
contention
connection occupancy

which means poorly designed transaction boundaries can indirectly degrade the entire system under load.

8. Deadlocks

Deadlocks occur when transactions wait on each other in a cycle, and neither can proceed. They occur when multiple transactions access shared resources in different orders and end up waiting on each other indefinitely.

For example:


Transaction A locks Row 1
Transaction B locks Row 2

Transaction A now waits for Row 2
Transaction B now waits for Row 1

Neither transaction can continue so the database resolves the deadlock by aborting one of them.

Deadlocks are a sign that the system does not have a consistent way of coordinating access.

One of the most effective ways to reduce deadlocks is maintaining consistent lock ordering.

For example, if multiple transactions must update two rows:

always lock the smaller ID first
always acquire resources in the same sequence

Keeping transactions short also matters.

The longer a transaction remains open:

the longer locks are held
the more overlap exists with other transactions
the higher the probability of contention

9. How These Problems Compound

One thing that makes production performance difficult is that these issues rarely appear independently.

A system may begin with a small N+1 pattern.

That increases query volume.

Higher query volume increases connection usage.

Connection pressure increases wait time.

Longer waits increase transaction duration.

Longer transactions increase lock contention.

More contention increases the likelihood of deadlocks and throughput collapse.

At that point, the system is no longer failing because of one slow query. The entire access pattern of the application has become unstable under concurrency.

10. Closing Thoughts

Most database performance issues are not caused by one catastrophic query. They usually emerge gradually from small inefficiencies that compound under load:

repeated queries
excessive payloads
inefficient indexing
poor transaction boundaries
uncontrolled concurrency

Many of these systems still feel “fast” early on, which is part of why these problems are easy to ignore initially.

The challenge is that production traffic changes the behavior of the system completely. Queries that once felt harmless begin repeating at scale, transactions overlap more aggressively, connection pressure increases, and small inefficiencies start compounding into system-wide bottlenecks.

At that point, database performance is no longer just about whether a query is fast. It becomes about whether the overall pattern of data access can still hold up under concurrency.

Idempotency Is Not Enough: Designing Deterministic Payment Systems

Rahman Nugar — Tue, 14 Apr 2026 05:49:49 +0000

In payment systems, duplicate processing is not a theoretical problem. It happens in ordinary, boring ways.

A user taps a payment button twice.
The network times out after the server has already processed the request.
A mobile client retries automatically.
A background worker replays a failed renewal.
A webhook arrives again. If the system is not designed carefully, any of those events can result in the same transaction being processed twice.

I recently worked on tightening the payment architecture in my company’s product, and this was one of the main problems I had to solve.

The usual answer is idempotency keys, and they are important. But on their own, they are not enough.

Duplicate processing in payment systems rarely comes only from obvious user behavior. More often, it emerges from retries, uncertain network boundaries, repeated webhooks, and recovery jobs. Idempotency keys help, but they only protect the request boundary. If the same logical transaction can still arrive with a different key, the system is not fully safe.

What I needed was not a best-effort duplicate check. I needed a payment flow that remained correct under retries, network uncertainty, repeated webhooks, and background recovery jobs.

This article explains the design pattern I implemented at my company to make payment flows deterministic:

client-generated idempotency keys for user actions
server-generated idempotency keys for system retries
business-level uniqueness enforced in the database
the database acting as the final source of truth

The Real Problem
What Idempotency Actually Solves
Why Idempotency Alone Is Not Enough
The Second Layer: Business-Level Uniqueness
Client Keys vs Server Keys
Retry Flows and Failure Recovery
Database as Final Source of Truth
The Design Trade-off
Closing Thoughts

When people discuss duplicate payments, they often frame it as a user-behavior problem.

“What if the user clicks twice?”

That is only one version of the problem.

In practice, duplicate financial processing usually comes from distributed system behavior:

the client does not know whether the first request completed
the server crashes after persisting state but before responding
a job runner retries after a timeout
an external payment provider sends the same event more than once

At that point, the question is no longer “did this request arrive twice?”

The real question is:

“Can this business operation be committed twice?”

This matters, because requests and business operations are not the same thing.

2. What Idempotency Actually Solves

Let's first define what the term means. Idempotency is a principle that ensures an operation can be performed multiple times without altering the result after the first execution. Idempotency keys enforce this principle by making repeated requests return the same outcome.

A client generates a key, attaches it to a write operation, and if the same request is replayed with the same key, the server returns the original result instead of processing it again.

This is extremely useful for:

network retries
client restarts
uncertain response delivery
safe replay of a user-initiated action

In other words, idempotency protects the request boundary.

3. Why Idempotency Alone Is Not Enough

Idempotency keys are designed to deduplicate requests, not business intent. They guarantee that the same key won't trigger the same operation twice but prove futile if the same transaction is submitted with a different key.

In practice, this happens constantly:

a client generates a fresh key on every retry
two devices initiate the same action independently
the same business intent is replayed from another workflow
a user refreshes and restarts the process

If the system relies only on idempotency keys, then a different key can make the same transaction appear new.

4. The Second Layer: Business-Level Uniqueness

To close that gap, we need a second rule:

the system must define what makes a transaction truly unique at the business level and enforce that rule in storage.

This design assumes that each business operation is anchored to a stable identifier (e.g. orderId, cartId, or subscriptionId) that is reused across retries. Without this, the system cannot deterministically detect duplicates.

This is where many systems stay too soft. They validate in application code, or they “check before insert,” but that still leaves room for race conditions.

The stronger approach is to define deterministic uniqueness around the transaction itself.

Examples:

an order payment for a specific actor and order ID
a subscription renewal for a specific subscription and billing period
a refund for a specific parent transaction
a slot renewal for a specific slot and renewal cycle

Once that business identity is clear, the database can enforce it with unique constraints or equivalent transaction-safe guards.

That gives the system a multi protection layer against duplicate processing:

idempotency key uniqueness at the request level
business identity uniqueness at the operation level

5. Client Keys vs Server Keys

Not every transaction originates from the same place, so not every key should be generated the same way.

For user actions, client-generated keys make sense.

Examples:

starting a checkout
upgrading a plan
purchasing an add-on

The client is the originator of the action, so it should generate the request identity.

For system actions, server-generated keys are more appropriate.

Examples:

retrying a failed subscription renewal
replaying a queued refund job
creating a new internal attempt after a provider error

In these flows, the system itself is the actor. The server owns the retry logic, so the server should generate the retry key.

6. Retry Flows and Failure Recovery

Retries are where payment systems get messy very quickly.

If retries are not modeled explicitly, the system often mutates the same record over and over, and after a while it becomes difficult to answer basic questions:

how many attempts were made?
which provider reference belongs to which attempt?
what actually failed?
what was retried automatically versus manually?

The cleaner approach is to treat each attempt as its own durable transaction record, linked back to the original business operation.

That gives you:

a stable business identity for the logical payment
a separate attempt history for operational recovery
bounded retries instead of untracked replay loops

This is especially important in subscription billing, where retries can happen long after the original charge attempt and often under degraded network or provider conditions.

7. Database as Final Source of Truth

Application code is not the strongest place to enforce financial correctness.

It is useful, but it is not final.

Two requests can race.
Two workers can run at the same time.
Two app instances can both decide something “does not exist yet.”

The only layer that sees the final committed write is the database.

That is why the database must be the last word on transaction uniqueness.

This is the principle I care about most in payment systems:

correctness should be deterministic, not heuristic.

A heuristic says:

“We usually catch duplicates.”

A deterministic system says:

“This duplicate cannot be committed.”

That difference becomes more important as the system grows, because retries, workers, webhooks, and concurrent clients all increase over time.

8. The Design Trade-off

This design is stricter than a simple idempotency-key implementation.

It introduces more explicit transaction modeling:

request identity
business identity
attempt history
retry limits

That is extra structure, but in financial flows, that structure pays for itself.

Without it, you eventually end up debugging ambiguity:

was this a duplicate charge or a second attempt?
did the user retry or did the worker retry?
is this the same renewal cycle or the next one?

Once the system treats transactions as durable business objects rather than transient HTTP events, those questions become much easier to answer.

9. Closing Thoughts

Idempotency keys are valuable, but they are only one part of a safe payment design.

If a different key can still trigger the same transaction twice, then the system is not truly protected.

The stronger model is:

use idempotency keys to make retries safe
define business-level uniqueness for the underlying transaction
enforce that uniqueness in the database
let the database act as the final source of truth

Idempotency keys are still one of the most useful tools in payment systems however I do not think they should be treated as the full solution.

They make repeated requests safer. They do not, on their own, define the true identity of a financial transaction.

Owlyn: Building a Multimodal Agent Ecosystem for Live Technical Interviews and Real-Time Assistance #GeminiLiveAgentChallenge

Rahman Nugar — Mon, 16 Mar 2026 17:48:40 +0000

The current landscape of technical hiring is bottlenecked by a fundamental scalability problem. Organizations receiving hundreds of applications per role find it impossible to conduct live, high-quality interviews for every candidate, often resorting to cold, non-immersive recordings or static tests. These traditional "AI interviews" are neither live nor engaging—they strip away the conversational nuance that defines a great engineer and leave both the company and the candidate with a fragmented view of technical potential.

We built Owlyn to solve this gap using real-time multimodal intelligence. Instead of a static AI assessment, Owlyn operates as an autonomous agent ecosystem capable of seeing, hearing, and reasoning about a candidate’s live workspace. By leveraging the Gemini Live API, Owlyn conducts real-time technical interviews and provides a persistent assistant mode that can see, hear, and interact with sub-second latency. Every interaction is synchronized with live transcripts, ensuring the system is both high-fidelity and accessible across every workflow.

Watch the Owlyn Demo on YouTube

This piece of content was written by me, Abdulrahmon Adenuga (@rahmannugar), along with Akeem Adetunji and Mosimiloluwa Adebisi and created for the purposes of entering the Google #GeminiLiveAgentChallenge hackathon. It covers how we built Owlyn using Google AI models and Google Cloud.

The Core Objectives
System Architecture
The Multi-Agent Protocol
Live Workflows: Interview, Monitoring, and Assistant
Recruitment Management: Dashboards and Talent Pools
Real-Time Multimodal Pipelines
Security: The Sentinel Mode
Engineering Decisions
Closing Thoughts and Future Roadmap

1. The Core Objectives

Existing AI interview tools often fail because they are built as wrappers around static LLMs, leading to two major deal-breakers: hallucination and latency. If an AI takes 5 seconds to respond, the conversation is dead. If it "guesses" what your code does instead of analyzing its logic, it loses all technical authority.

To solve this, we defined four design pillars for Owlyn:

Zero-Latency: Using Gemini Live to achieve sub-second response times, this eliminates the "awkward silence" typical of LLM-based bots, ensuring the conversation maintains the natural momentum of a real-world technical discussion.
Multimodal Reasoning: The agent must do more than listen; it must "see" the workspace. By streaming the screen feed, the agent can react to a candidate's cursor movements or a logic error in a whiteboard diagram.
Inclusive Accessibility: Building a system that is accessible to everyone. This means supporting multiple spoken languages and providing live transcripts for candidates with hearing disabilities, ensuring that automation doesn't come at the cost of inclusion.

2. System Architecture

Owlyn is designed as a distributed, real-time multimodal system composed of four major layers:

Electron Client Layer
Backend Orchestration Layer
Worker Agent Layer
Infrastructure & AI Layer

This separation allows the system to maintain sub-second conversational latency, while supporting multiple AI agents analyzing different signals simultaneously.

2.1 Electron Client Layer

The client application is built with Electron + React, which allows Owlyn to access system-level capabilities that are unavailable in the browser.

The Electron frontend is responsible for:

Capturing camera, microphone, and screen feeds
Rendering the Monaco coding workspace
Streaming audio/video via WebRTC
Sending application events to the backend via HTTPS REST

The client communicates with the backend in two ways:

HTTPS / REST
Used for:

Authentication
Session creation
Interview configuration
transcript synchronization

LiveKit WebRTC
Used for low-latency real-time streams:

microphone audio
webcam video
workspace signals

These streams are routed to the backend orchestration layer and AI agents.

2.2 Backend Orchestration Layer

The backend is built using Spring Boot and acts as the central orchestrator of the entire system.

Rather than allowing each AI agent to independently connect to the client, all signals pass through the backend first. This ensures:

consistent session state
controlled AI communication
centralized logging and monitoring

The backend exposes two internal interfaces:

REST API
Handles standard application workflows:

interview creation
candidate session management
transcript storage
session metadata

Internal API
Used for agent-to-agent communication and system orchestration.
This internal API connects to the Assessor Agent, which performs post-interview analysis and scoring.

2.3 Worker Agent Layer

Owlyn runs several specialized Python worker agents responsible for processing multimodal signals during a session.
These agents operate independently from the core backend to keep real-time processing lightweight.

LiveKit Agent
The LiveKit Agent connects to the LiveKit WebRTC stream and manages:

real-time voice conversation
audio streaming to Gemini Live
returning AI responses to the candidate

This forms the primary conversational loop of the interview.

Proctor Sentinel
The Integrity Sentinel monitors the webcam feed to ensure the session remains secure.
Using Gemini Vision, it detects:

unauthorized devices
additional people in frame
suspicious behavior
environmental anomalies

Any violation is immediately flagged and logged.

Workspace Sentinel
The Workspace Sentinel observes the candidate’s coding environment, including:

Monaco editor
whiteboard interactions
cursor behavior
code structure

It continuously analyzes implementation logic and forwards observations to the Interviewer agent so the conversation can react to the candidate’s code in real time.

2.4 Infrastructure and AI Layer

The final layer provides the persistent infrastructure and AI services that power the system.

Dockerized PostgreSQL & Redis
We utilize Docker to containerize our data layer, ensuring a consistent and isolated environment for both PostgreSQL and Redis.

PostgreSQL: Handles durable storage for interview sessions, transcripts, reports, and user data. It is accessed through the Spring Boot backend via JPA.
Redis: Stores live session state (transcript buffers, agent context, security flags) for sub-millisecond updates during live conversations.

Note on Backend Deployment: The Owlyn backend (orchestration layer and worker agents) is hosted on Google Cloud Virtual Machines (VMs). This provides the stable, high-performance environment necessary for sub-second multimodal processing and session management.

LiveKit Server
LiveKit acts as the real-time media server for Owlyn.
It manages:

WebRTC signaling
audio/video transport
stream synchronization

This allows voice conversations to occur with sub-second latency, which is critical for maintaining natural dialogue.

Gemini AI
Owlyn integrates multiple Gemini models for specialized reasoning tasks:

Gemini Live API → real-time voice conversation
Gemini 3.1 Pro → deeper reasoning and evaluation
Gemini 3 Flash → lightweight real-time inference
Gemini Vision → visual analysis of the workspace and webcam Each model powers a different agent in the system.

2.5 Cross-System Communication Flow

During a live interview session, the system operates as a continuous pipeline:

The Electron client streams audio/video via LiveKit.

The Spring Boot backend orchestrates session state.

Python agents process multimodal signals in parallel.

Signals are routed to Gemini AI models for reasoning.

Results are returned through LiveKit to the candidate in real time.

Redis stores live context while PostgreSQL stores persistent records.

This architecture allows Owlyn to maintain low latency, contextual awareness, and modular AI reasoning, enabling the system to behave less like a scripted bot and more like a real technical interviewer.

3. The Multi-Agent Protocol

Owlyn is built on a decoupled multi-agent architecture. We designed the system from the ground up using specialized Gemini instances for distinct tasks; voice interaction, workspace vision, and real-time code analysis rather than relying on a single monolithic agent. This ensures that the interviewer remains grounded by the candidate's actual workspace signals while maintaining sub-second conversational latency.

The Orchestrator is our server. Since Gemini agents can't directly talk to each other without a shared context, the Orchestrator acts as the central router. It receives video and audio via WebRTC, pipes them to the correct Gemini model, and then relays context between the different agents. This ensures the interviewer can react to a failing test case or a specific logic choice in real-time.

Agent 1: The Question Generator (Gemini 3 Flash Preview): This agent runs during the interview creation phase on the management dashboard. It analyzes the job role and requirement details to draft specific technical challenges and coding tasks. This ensures the interviewer (Agent 2) has a tailored set of objectives ready before the candidate even starts the session.
Agent 2: The Interviewer (Gemini Live): This is the conversational agent the candidate hears. It handles the voice loop with sub-second latency, maintaining a natural dialogue flow throughout the session.
Agent 3: The Sentinels (Gemini 3.1 Flash Lite): These are the specialized "eyes" and "ears" of the system.
- Integrity Sentinel: Processes the video feed to monitor session security and detect unauthorized activity.
- Workspace Sentinel: Observes the Monaco editor and whiteboard. It analyzes the implementation logic in real-time, providing deep structural insights to the interviewer.
Agent 4: The Technical Assessor (Gemini 3): Once the interview ends, this agent takes the full transcript and the logic reasoning logs to generate a structured JSON report. It looks purely at the data to give an unbiased score.

graph LR
    %% Phase 1: Setup
    subgraph Setup ["1. Pre-Interview Setup"]
        Start(Job Role) --> A1[Agent 1: Question Generator]
        A1 -- "Drafts" --> Tasks(Technical Tasks)
    end

    %% Phase 2: Live
    subgraph Interaction ["2. Live Interaction"]
        Candidate((Candidate)) <--> |LiveKit WebRTC| Orch[Spring Boot Orchestrator]
        Orch <--> A2[Agent 2: Gemini Live Interviewer]
        Orch <--> A3[Agent 3: Workspace Sentinels]
        A3 -- "Visual & Code Feed" --> A2
    end

    %% Phase 3: Reporting
    subgraph Evaluation ["3. Final Scoring"]
        Interaction -- "Session Logs" --> Data(Transcripts & Context)
        Data --> A4[Agent 4: Technical Assessor]
        A4 -- "Report" --> Result(Unbiased Score)
    end

    %% Logic Flow
    Tasks -.-> A2

This "Agent-to-Agent" handoff is what makes Owlyn feel smart. When Agent 3 identifies a logic error in your code, it tells Agent 2: "Hey, their solution might have a performance issue." Agent 2 then asks the candidate: "I noticed your current approach might have some performance challenges. Can you walk me through your time complexity?"

Persona Customization: Defining the Interviewer

We built a Persona Engine to move away from a "one-size-fits-all" agent ecosystem. Recruiters can configure their agents' behavior through several technical levers in the management dashboard:

Linguistic Localization: The spoken language can be set per session, supporting English, German, Spanish, French, and several other locales for a global candidate pool.
Behavioral Scalars: Instead of basic prompts, we use weighted scores for Empathy, Analytical Depth, and Directness. These values are injected into the agent's core instructions to shift the tone from a supportive guide to a rigorous technical evaluator.
Document-Based Knowledge: Recruiters can upload PDFs or DOCX files—such as internal engineering rubrics or company values—which the system parses and uses to inform the agent's specific technical knowledge during the session.

4. Live Workflows: Interview, Monitoring, and Assistant

We didn't just stop at an interview screen. We built four distinct ways to use Owlyn. Across all modes, we prioritized accessibility through Live Transcripts. For developers with hearing disabilities or those in noisy environments, Owlyn provides a threaded, real-time transcript of every word the agent says. This ensures the system remains inclusive and that the agent's logic can be read and reviewed as it happens.

A. The Interview Workspace

This is the core experience. The candidate has a professional-grade workspace with the Monaco Editor, a canvas-based Whiteboard, and a Notes app. Everything is synced in real-time.

Support for Multiple Programming Languages

We engineered the workspace to be language-agnostic. By utilizing Monaco Editor (the engine behind VS Code), Owlyn provides a native coding experience for over 20+ languages, including Typescript, Python, Go, Java, and C++. The Workspace Sentinel (Agent 3) is specifically tuned to understand the idiomatic nuances of these languages, ensuring that whether a candidate is writing a high-performance Go routine or a clean React component, the evaluation remains context-aware and accurate.

B. Monitoring Mode

For organizations, visibility is just as important as the evaluation itself. We built a Monitoring Dashboard that serves as a real-time command center for recruitment teams.

Hiring managers can join any active session as a "Silent Observer," gaining a comprehensive view of the candidate’s performance without interfering with the natural flow of the interview. The dashboard provides a live, rolling transcript, a synchronized audio waveform to visualize the conversation's cadence, and an instant alert system. If our sentinels detect a security anomaly—such as the presence of a mobile device or an unauthorized person in the frame—a flag is immediately raised on the recruiter's screen, allowing for instant intervention if necessary.

C. Assistant Mode

Assistant Mode transforms Owlyn into a persistent multimodal companion for everyday development. Beyond the interview, this mode operates as a floating widget that lives alongside your IDE and terminal.

Environmental Context: The agent utilizes screen-share vision and your microphone to stay synchronized with your active tasks.
Voice-First Interaction: Leveraging the LiveKit protocol for sub-second responses, it acts as a senior pair-programmer you can talk to in real-time.
Ambient Assistance: Whether you're debugging a complex stack trace or architecting a new service, the Assistant provides contextual insights based on exactly what it sees on your screen.

D. Practice Mode

Before entering a real technical interview session, candidates need a way to test their technical skills and get comfortable with the interview environment. We built Practice Mode as a standalone version of the workspace where users define their own parameters:

Customizable Sessions: Users input a specific topic (e.g., "React Performance" or "Distributed Systems") and set a difficulty and timer. The agent then dynamically generates a technical session based on those constraints. --Multi Language Support: Users can select their preferred language from the list of supported languages. This instructs the AI agent to communicate with the candidate in their preferred language.
Protocol Parity: It uses the same multi-agent orchestration, audio/video streaming, and code analysis as the Enterprise mode. This ensures the candidate is getting the real experience in a private environment.

5. Recruitment Management: Dashboards and Talent Pools

Technical hiring is about more than just one interview; it is about managing many candidates effectively across an entire company. We built a management system to help teams handle their hiring process from start to finish:

The Recruitment Dashboard

This is the main control center where hiring teams manage their daily work. It shows what is happening in the company right now:

Track Candidates in Real-Time: Managers can see which candidates are waiting in the lobby, which interviews are currently live, and which ones are finished. This helps teams stay organized during busy hiring seasons.
Role-Based Customization: Recruiters can set different rules for different positions. You can choose the language the AI speaks and set how strict it should be. For example, you can make the AI a helpful guide for a junior developer or a very rigorous judge for a senior lead. You can also upload specific coding tasks for each role.
Human Decision Making (Hire or Decline): While the AI handles the interview, the final choice always belongs to a human. After the interview, a recruiter reviews the technical report and uses the Hire or Decline buttons to make a final evaluation. This ensures that a real person always has the last word.

Team Collaboration

Hiring is a team sport. We added features to help engineering leads and recruiters work together:

Team Management: Organizations can invite multiple team members to the dashboard. This allows different people to review the same candidate report and share their feedback.
Shared Feedback: Recruiters can leave notes on a candidate's profile for other team members to see. This helps build a complete picture of the candidate’s performance from different perspectives.

Analysis and Reporting

Once an interview is over, the AI generates a detailed technical report. This report is the primary tool recruiters use to make their hiring decisions:

Technical Radar Charts: The system visualizes candidate skills (like Problem Solving, Communication, and Code Quality) on a radar chart. This makes it easy to see at a glance where a candidate is strongest.
Full Transcripts and Code History: Recruiters can read every word said during the interview and see exactly how the candidate's code evolved over time.
Automated Summary: The AI provides a short summary of the candidate's performance, highlighting both their strengths and their mistakes.

The Talent Pool

The Talent Pool is a central library where all candidate results are kept. It helps teams find the best talent faster:

Compare Skills Side-by-Side: The system takes the AI's technical scores and puts them in a simple table. This lets recruiters filter candidates by their score or role, making it easy to see who performed best across hundreds of sessions.
Talent Analytics: The dashboard shows overall stats for your hiring pipeline, such as the total number of candidates, the percentage of high-potential profiles, and the average score for a specific role.
Exporting for Teams: Recruiters can export lists of elite candidates to share with other departments, ensuring that top talent is never lost in the system.
Unbiased Ranking: Because the AI scores everyone using the same technical rules, the Talent Pool gives teams an objective way to rank people based on their actual coding ability.

6. Real-Time Multimodal Pipelines

Capturing human interaction for an autonomous agent is technically demanding. We had to solve for two main things: data shape and latency.

For the Video Feed, we stream 1 frame per second. We found this to be the "sweet spot" for Gemini’s Vision capabilities—it’s enough to detect a phone or a change in gaze without destroying the candidate's upload bandwidth.

For Audio, we use 16kHz mono PCM. This is streamed up to our Java server, which then pipes it directly into the Gemini Live API via the Google ADK. We spent a lot of time on the audio.service.ts to ensure that audio chunks are small enough for low latency but large enough to maintain quality.

7. Security: The Sentinel Mode

Integrity is non-negotiable for professional assessments. We implemented what we call Sentinel Mode to protect the session:

OS-Level Lockdown: We use Electron's globalShortcut to block navigation and win.setContentProtection(true) to make the screen appear black to recording software like OBS.
Environmental Breach Detection: We listen for "blur" events. If the candidate switches windows, it’s logged as a breach, and the agent verbally warns them to focus.
Vision-Based Security Monitoring: Since Gemini is looking at the 1fps feed, it natively detects unauthorized objects (phones, tablets) or external participants in the room.

8. Engineering Decisions

Every engineering project is a series of trade-offs.

Latency vs. Accuracy: We chose 1fps for the vision feed over a smoother 10fps. While less "fluid," it ensures that candidates on a standard home connection can participate without lag or video fragmentation.
Centralized Session Orchestration: We chose to coordinate multiple agents through our Spring Boot backend rather than having the client manage separate peer-to-peer connections with 4+ different Gemini models. While this centralization adds architectural complexity, it was essential for maintaining a unified state across the Interviewer, Workspace Sentinel, and Integrity Sentinel.
In-Context Logic Verification: We leveraged Gemini’s specialized reasoning models to verify logic in real-time. This avoided the overhead of a formal execution sandbox while allowing the agent to provide feedback on implementation details as they unfold.
Memory-First State Management: We use Redis for all active session data (transcripts, flags, editor state). This sacrifices the "safety" of persistent disk writes for the sub-millisecond updates required in a live, voice-driven environment.

9. Closing Thoughts and Future Roadmap

Building Owlyn for the #GeminiLiveAgentChallenge allowed us to move beyond traditional AI interviews by creating a truly live and immersive workspace. By synchronizing voice and vision, we’ve enabled both high-fidelity technical assessments and a persistent assistant mode for everyday development. We see this multimodal synergy as the new standard for how technical talent is discovered, validated, and empowered in a high-stakes engineering world.

Looking forward, we’re expanding the Owlyn ecosystem with the following roadmap:

Team-Based Mode: Moving beyond silent monitoring to allow recruiters to "jump in" to the live session at any point. This enables a hybrid workflow where a human interviewer can take over the lead from the AI for a final, high-fidelity cultural evaluation.
Deeper ATS Integration: One-click exports to tools like Greenhouse or Lever to automate the hiring funnel.
Collaborative Whiteboarding: Support for real-time collaboration between the agent and candidate on the same whiteboard canvas.

Building this for the #GeminiLiveAgentChallenge has been an incredible experience, and we’re just getting started. 🦉

The Owlyn Team

Code Repository

Frontend: https://github.com/A-Simie/Owlyn
Backend: https://github.com/Akeem1955/OwlynBackend

Contributor	GitHub Profile
Mosimiloluwa Adebisi	@A-Simie
Akeem Adetunji	@akeem
Adenuga Abdulrahmon	@Rahmannugar

Suite 33: A business management platform for SMEs.

Rahman Nugar — Thu, 27 Nov 2025 01:26:49 +0000

Running a small or medium sized business is difficult enough when operations are structured. Small and medium sized enterprises often rely on manual processes to run their operations. Sales are recorded on paper, inventory is tracked informally, payroll is handled in notebooks, and staff performance is evaluated without any structured system. These gaps often create delays, inaccuracies which is detrimental to business growth.

Suite33 was created to close those gaps. It is a business management platform designed specifically for SMEs. The goal is simple. Build a digital system that reflects how small businesses already work, while making their day to day operations cleaner, faster and easier to track.

Live Link - Suite33

1. Why Suite33 Was Built
2. Understanding the Challenges SMEs Face
3. Designing the Suite33 Experience
4. Getting Started: Onboarding and Setup
5. The Modules That Shape Suite33
6. Business Security and Roles
7. Lessons Learned While Building Suite33
8. Closing Thoughts

1. Why Suite33 Was Built

Suite33 did not begin as a random idea. It came from firsthand experience.
Recently, I was consulting with a business and I quickly noticed they ran their entire business activities with unorganized records. The business owner had no central view of how the business was performing. Decisions were made from instinct instead of data. It became clear that these businesses needed structure, hence Suite33.

2. Understanding the Challenges SMEs Face

Before writing a line of code, it was important to understand the real problems facing several SMEs in Nigeria.

After a thorough case study, I was able to draft out some of the most common issues:

Sales records disappear easily because they are written in notebooks or loose sheets.
Inventory is uncertain, making it difficult to know what is available at any moment.
Payroll takes too long, especially when each staff salary is calculated manually.
Staff performance is subjective, with no historical score or monthly evaluation.
Financial insights are unclear, since there is no unified view of revenue, spending and profit.

3. Designing the Suite33 Experience

I modelled Suite33 around clarity and structure. Instead of building a complex enterprise style system, the goal was to create something simple enough for daily use but powerful enough to rely on.

Every screen, every form and every action follows three principles:

1. Keep the workflow familiar
If a business is used to notebooks, Suite33 should feel like a digital extension of that, not a replacement that forces new habits.

2. Reduce cognitive load
No cluttered screens, no confusing menus. Businesses should be able to understand their data at a glance.

3. Centralize everything
Sales, expenses, inventory, payroll, staff and KPIs should all be centralized in a single dashboard application.

This approach ensured that Suite33 could serve small teams without overwhelming them.

4. Getting Started: Onboarding and Setup

The onboarding flow guides the business into the platform step by step.

Business Setup
Users begin by providing the essential details:

Business name
Industry
Location
Optional Business logo

This immediately personalizes the workspace and prepares the environment for operations.

Inviting Staff
Admins can invite up to 10 staff members per month.
This limit is intentional. It encourages businesses to gradually set up their team and ensures the system remains manageable during early adoption.
Staff receive an email and join the business with their own login. Their roles determine what they can access in the platform.

Editing Profile
Every user can update their personal information. This includes updating name, avatar.

5. The Modules That Shape Suite33

Suite33 contains several core modules, each responsible for one part of the business operation. They are connected behind the scenes, which allows the dashboard to generate a complete view of business performance.

Sales Management
The sales module makes it easy for businesses to record daily sales and monitor revenue trends over time.
With the ability to track monthly progress, visualize data export results and gain insights, SMEs finally gain clarity about how their business is performing. This transforms guesswork into informed decisions.

Expenditures
For a business to truly understand its profit margins, it must first understand spending.
Suite33 allows businesses to log every expense, categorize it and review spending patterns throughout the year. Every expenditure feeds directly into the dashboard’s profit and loss calculation.

Inventory Management
Inventory issues are one of the biggest pain points for SMEs. Suite33 simplifies this process with a clean, structured layout.

Businesses can:

Create categories
Add new inventory items
Track quantities
Edit details as stock changes
Export inventory lists
View low stock

The system prevents accidental deletion of categories that still contain items, protecting the integrity of the data.

Payroll
Payroll is often the most repetitive and time consuming task for SMEs. Suite33 introduces a monthly payroll batch system that automates most of the work.

Each month:

The admin generates a batch.
Staff salaries are automatically included.
Admin can update staff salaries and mark each staff as paid or unpaid.
When the batch is complete, it can be locked to prevent accidental changes.
Staff can view their payslip privately.
Admins can export the payroll to Excel or CSV.

Staff Management
Staff records are organized in one place. Admins can:

Add new staff
Remove staff
Edit roles
Assign departments
Staff only see information relevant to them.

KPI Tracking
Performance evaluation becomes simpler with monthly KPI scoring.
Instead of relying on memory or last minute judgments, businesses can maintain a consistent record of how each staff performs throughout the year.
KPI scores help guide promotions, reviews and improvements.

Dashboard Overview
The dashboard is the heart of Suite33.
It brings together data from every module to give the business a complete operational overview.

The dashboard displays:

Sales summary
Expenditures summary
Staff count
Inventory count
Payroll status
Profit and loss table
Business identity This allows business owners to view their financial and operational health at a glance.

6. Business Security and Roles

Suite33 is structured around three access levels:

Admin

Full access to all operations and business management.

Sub Admin(Assistant Admin)

Support role with management access but limited payroll visibility.

Staff

Restricted access with visibility limited to personal payslips and details.

This structure ensures privacy, accountability and security on all fronts.

8. Lessons Learned While Building Suite33

Building Suite33 revealed several important insights about SMEs and software design.

1. SMEs value simplicity above all else
Most small businesses do not need complex systems. They need clarity. They need something that simplifies their existing processes instead of replacing them.

2. Onboarding is as important as the product
Businesses lose interest quickly if the first steps feel overwhelming. Refining onboarding to be quick and human centered made adoption smoother.

3. Accuracy is everything when dealing with money
Payroll and financial modules must leave no room for uncertainty. The smallest error can create distrust. Ensuring reliability at every stage became a priority.

4. A business cannot grow without visibility
SMEs often operate in the dark. When they finally see their numbers clearly, they make better decisions. Data presentation mattered just as much as data storage.

5. Scalability is not only about technology
It is also about designing workflows that still make sense when the business grows from 5 staff to 50 staff. Features were built to feel predictable, even when usage increases.

6. Every role needs a different view of the system
Admins do not need the same interface as staff, and staff should never see what belongs only to administrators. Clear separation of roles became essential.

8. Closing Thoughts

Suite33 is designed to give SMEs a more organized way to run their business. It replaces manual processes with a single system that tracks sales, inventory, expenses, payroll and staff performance in one place.

The platform does not aim to complicate operations. Instead, it brings the structure small businesses need to work more efficiently and make informed decisions.

As SMEs continue to grow, Suite33 gives them a dependable foundation to grow on.

Contemporary State Management and Data Operations in React

Rahman Nugar — Thu, 16 Oct 2025 13:29:14 +0000

Tools evolve, trends change.

React introduced developers to a new way of thinking about UI, where components react to data and user interactions in real time. It started as a simple idea: manage state locally and let the UI update automatically. But as applications grew more complex, so did the challenge of handling state that needed to live across many parts of an app.

Fast forward to currentDate(), and we’ve come a long way from simple useState and useEffect for state management and data fetching respectively. Today, React developers work with Context API, Zustand, Redux Toolkit, for managing state and TanStack Query, RTK Query, server side fetching(Nextjs) for querying or mutating data. Each tool solves a slightly different problem, and knowing which one to use for a particular project makes all the difference.

In this article, we’ll take a detailed look at modern state management, data query and mutation in React. You’ll learn when each tool shines, how they fit together, and how to make the most of them in a modern React app.

Understanding React’s Core State Model
Context API: The Native Option
Zustand: Lightweight Yet Scalable
Redux Toolkit: Predictable and Enterprise-Ready
useEffect: The Misused Hook
TanStack Query
RTK Query
ServerSide Fetching
Patterns and Best Practices
Conclusion

1. Understanding React’s Core State Model

Before looking at the aforementioned contemporary tools, it’s worth revisiting the basics.

React’s design encourages predictable, unidirectional data flow. Each component has its own state, typically managed with hooks like useState and useReducer.

Usestate

const [name, setName] = useState("Nugar");

This works perfectly for local, isolated state such as toggling a modal or tracking form input.

For more complex scenarios, developers often use useReducer for clearer state transitions:

UseReducer

const initialState = { isOpen: false, modalType: null };

function reducer(state, action) {
  switch (action.type) {
    case "OPEN_MODAL": return { isOpen: true, modalType: action.payload };
    case "CLOSE_MODAL": return { isOpen: false, modalType: null };
    default: return state;
  }
}

const [state, dispatch] = useReducer(reducer, initialState);

The problem arises when different components need access to the same data. Manually passing props up and down the tree leads to “prop drilling,” which quickly becomes difficult to maintain. This is where global state solutions step in.

2. Context API: The Native Option

The Context API is React’s built-in way to share data globally across components without prop drilling. It’s simple, dependency-free, and ideal for small applications or simple global state.

// theme-context.tsx
import { createContext, useContext, useState } from "react";

const ThemeContext = createContext(null);

export const ThemeProvider = ({ children }) => {
  const [theme, setTheme] = useState("light");
  const toggleTheme = () => setTheme(t => (t === "light" ? "dark" : "light"));

  return (
    <ThemeContext.Provider value={{ theme, toggleTheme }}>
      {children}
    </ThemeContext.Provider>
  );
};

export const useTheme = () => useContext(ThemeContext);

Then in any component:

const { theme, toggleTheme } = useTheme();

When to Use

Small projects or simple global state
Shared values like theme, language, or authentication status

Limitations

Can trigger re-renders across all consuming components
Becomes hard to manage as the app grows
Not ideal for frequent or performance-sensitive updates

The Context API shines for lightweight scenarios, but once your application grows or requires complex state logic, a dedicated library becomes a better fit.

3. Zustand: Lightweight Yet Scalable

Zustand has become a favorite among developers for its simplicity and performance. It provides a minimal, intuitive API that lets you create global stores without providers or reducers. I frequently use Zustand nowadays for projects that require global state management due to its simplicity and ease of use.

import { create } from "zustand";

const useUserStore = create(set => ({
  user: null,
  setUser: user => set({ user }),
  logout: () => set({ user: null })
}));

Usage

const { user, setUser, logout } = useUserStore();

No boilerplate, no extra setup. Zustand uses shallow comparison to prevent unnecessary re-renders, keeping your app fast and efficient.

Why Developers Love It

Minimal API and easy learning curve
Excellent TypeScript support
Works great for UI and session state
Supports persistence, middlewares, and subscriptions

When to Use

Small to medium projects that need global state
Applications with local caching or session management

4. Redux Toolkit: Predictable and Enterprise-Ready

Redux has been around for years, and while it used to be associated with boilerplate and verbosity, Redux Toolkit (RTK) changed that. RTK provides structured, opinionated utilities that simplify reducers, actions, and store configuration.

import { configureStore, createSlice, PayloadAction } from "@reduxjs/toolkit";

interface AuthState {
  user: { name: string } | null;
}

const initialState: AuthState = { user: null };

const authSlice = createSlice({
  name: "auth",
  initialState,
  reducers: {
    login: (state, action: PayloadAction<{ name: string }>) => {
      state.user = action.payload;
    },
    logout: state => {
      state.user = null;
    },
  },
});

export const { login, logout } = authSlice.actions;
export const store = configureStore({ reducer: { auth: authSlice.reducer } });
export type RootState = ReturnType<typeof store.getState>;
export type AppDispatch = typeof store.dispatch;

Usage

import { useSelector, useDispatch } from "react-redux";
import { login, logout, RootState } from "./store";

export default function App() {
  const user = useSelector((state: RootState) => state.auth.user);
  const dispatch = useDispatch();

  return user ? (
    <button onClick={() => dispatch(logout())}>Logout</button>
  ) : (
    <button onClick={() => dispatch(login({ name: "Rahman" }))}>Login</button>
  );
}

5. useEffect: The Misused Hook

Before exploring modern data-fetching solutions, it’s important to talk about useEffect, a hook that was never designed for fetching or mutating data, yet became the default tool for it in most React apps.

When React Hooks were introduced, useEffect filled an essential gap in functional components. It allowed developers to perform side effects; actions that happen outside React’s rendering cycle. These effects include subscribing to events, updating the document title, managing timers, or synchronizing state with browser APIs.

In simple terms, useEffect lets your component “reach outside” React’s pure rendering world and interact with the environment.

useEffect(() => {
  document.title = `Hello, ${userName}`;
}, [userName]);

This is a perfect use case: the effect reacts to changes in userName and synchronizes the browser title accordingly.

However, over time, developers began using useEffect for something it wasn’t built for — data fetching and mutation.

useEffect(() => {
  async function loadUser() {
    const res = await fetch("/api/user");
    const data = await res.json();
    setUser(data);
  }
  loadUser();
}, []);

While this pattern works for small applications, it quickly becomes fragile as your app grows.

Why useEffect Is a Poor Fit for Data Operations

It Easily Re-Triggers Requests
It Doesn’t Handle Caching or Syncing
It Causes Race Conditions
It Adds Manual Overhead

These problems have even caused real-world incidents. Recently, Cloudflare experienced a large-scale performance issue that stemmed from an application repeatedly firing API calls due to misused React effects. The component’s re-renders multiplied outgoing requests, consuming massive internal bandwidth. The problem wasn’t React, it was a hook used for something beyond its purpose.

What useEffect Was Actually Meant For
The React team’s intention for useEffect has always been clear:

Setting up subscriptions or event listeners
Managing timers, intervals, or animations
Interacting with browser or third-party APIs
Cleaning up resources when a component unmounts

These are side effects, they are interactions that depend on or modify something outside of React’s data flow.

Fetching data, however, is a data flow operation, not a side effect. It belongs in a layer that manages caching, background refetching, synchronization, and invalidation. That’s far beyond what useEffect was built to handle.

Modern Tools Do It Differently
Libraries like React Query, RTK Query, and frameworks like Next.js have redefined how React handles data operations.

These tools aren’t built on top of useEffect. Instead, they use dedicated data layers that integrate deeply with React’s rendering engine, concurrent features, and Suspense. They know when to fetch, how to cache, and when to revalidate, all without you manually orchestrating it.

In modern React, useEffect should be reserved for what it was meant to do: handling external side effects at the component level. For data fetching, the ecosystem has evolved, and the right tools now exist to handle that responsibility cleanly and efficiently.

6. TanStack Query: Data Fetching Made Declarative

TanStack Query formerly known as React Query introduced a fundamental shift in how developers think about server data. Instead of manually managing loading, error, and caching logic, React Query abstracts those concerns behind a declarative API. It treats data as a cache that stays in sync with the server, not as temporary state inside your component.

TanStack Query revolves around two main concepts:

Queries for reading data (fetching)
Mutations for writing or updating data (creating, editing, deleting) Both are managed within a powerful caching layer that automatically keeps your UI in sync with your backend.

Query Example

import { useQuery } from "@tanstack/react-query";

function UserProfile() {
  const { data, isLoading, isError } = useQuery({
    queryKey: ["user"],
    queryFn: async () => {
      const res = await fetch("/api/user");
      if (!res.ok) throw new Error("Failed to fetch user");
      return res.json();
    },
  });

  if (isLoading) return <p>Loading...</p>;
  if (isError) return <p>Something went wrong.</p>;

  return <h2>Welcome back, {data.name}</h2>;
}

This hook handles fetching, caching, and background refetching automatically. When the queryKey changes, React Query knows it’s a different dataset and fetches accordingly.

Mutation Example

import { useMutation, useQueryClient } from "@tanstack/react-query";
function UpdateUser() {
  const queryClient = useQueryClient();

  const mutation = useMutation({
    mutationFn: async (user) => {
      const res = await fetch("/api/user", {
        method: "PUT",
        headers: { "Content-Type": "application/json" },
        body: JSON.stringify(user),
      });
      if (!res.ok) throw new Error("Failed to update user");
      return res.json();
    },
    onSuccess: () => {
      // Automatically refresh user data
      queryClient.invalidateQueries(["user"]);
    },
  });

  const handleUpdate = () => {
    mutation.mutate({ name: "Rahman Nugar" });
  };

  return (
    <button onClick={handleUpdate} disabled={mutation.isPending}>
      {mutation.isPending ? "Updating..." : "Update Profile"}
    </button>
  );
}

TanStack Query handles retries, optimistic updates, and cache synchronization under the hood, freeing you from manually tracking loading or error states.

Why It Matters

Queries cache data and refresh it only when needed.
Mutations update the server and sync local caches automatically.
Background updates ensure your data stays fresh without blocking UI rendering.

7. RTK Query: Redux-Powered Data Management

While TanStack Query is a standalone solution, RTK Query extends the Redux Toolkit ecosystem with an integrated data-fetching layer. It’s ideal if you already use Redux for state management but want modern, efficient data handling without extra libraries.

RTK Query provides similar declarative querying and mutation features but ties them directly into your Redux store.

Setting Up RTK Query

import { createApi, fetchBaseQuery } from "@reduxjs/toolkit/query/react";

export const userApi = createApi({
  reducerPath: "userApi",
  baseQuery: fetchBaseQuery({ baseUrl: "/api" }),
  endpoints: (builder) => ({
    getUser: builder.query({
      query: () => "/user",
    }),
    updateUser: builder.mutation({
      query: (user) => ({
        url: "/user",
        method: "PUT",
        body: user,
      }),
    }),
  }),
});

export const { useGetUserQuery, useUpdateUserMutation } = userApi;

Integrate it into your Redux store:

import { configureStore } from "@reduxjs/toolkit";
import { userApi } from "./userApi";

export const store = configureStore({
  reducer: {
    [userApi.reducerPath]: userApi.reducer,
  },
  middleware: (getDefaultMiddleware) =>
    getDefaultMiddleware().concat(userApi.middleware),
});

Using Queries and Mutations

function User() {
  const { data, isLoading } = useGetUserQuery();
  const [updateUser, { isLoading: isUpdating }] = useUpdateUserMutation();

  if (isLoading) return <p>Loading user...</p>;

  return (
    <div>
      <h2>{data.name}</h2>
      <button
        onClick={() => updateUser({ name: "Rahman Nugar" })}
        disabled={isUpdating}
      >
        {isUpdating ? "Updating..." : "Update"}
      </button>
    </div>
  );
}

RTK Query automatically caches responses, invalidates old data after mutations, and deduplicates concurrent requests while keeping data in Redux for predictable debugging and inspection.

When to Use RTK Query

You’re already using Redux Toolkit.
You want a single source of truth for both app and server state.
You need integrated caching and request lifecycle management.

8. ServerSide Fetching(Nextjs)

With frameworks like Next.js, data fetching moved beyond the client. Instead of fetching data after rendering, Next.js introduced ways to prefetch data on the server through getServerSideProps, getStaticProps, and, more recently, the Server Components model.

Server fetching shifts the data-fetching responsibility to the server layer, improving performance, SEO, and initial load times.

Example with Server Components
In the App Router (app/ directory), you can fetch data directly on the server without using useEffect or any client-side hooks:

// app/page.tsx
async function getUser() {
  const res = await fetch("https://api.example.com/user", {
    cache: "no-store",
  });
  return res.json();
}

export default async function Page() {
  const user = await getUser();

  return (
    <section>
      <h1>Welcome, {user.name}</h1>
    </section>
  );
}

Mutations in Next.js
With the new Server Actions, Next.js now supports secure, server-side mutations as well:

"use server";

export async function updateUser(data: { name: string }) {
  await fetch("https://api.example.com/user", {
    method: "PUT",
    headers: { "Content-Type": "application/json" },
    body: JSON.stringify(data),
  });
}

These actions can be directly called from client components using forms or event handlers, eliminating API route overhead while maintaining security and performance.

When to Use

Apps with strong SEO needs or public-facing content
Projects that rely on fast, server-rendered pages
Scenarios where data privacy and server security matter

9. Patterns and Best Practices

1. Separate UI State from Server State
Keep client-side UI logic (like modals or form inputs) separate from server-synced data.

2. Use useEffect Only for True Side Effects
Reserve it for browser interactions, subscriptions, or third-party integrations not data fetching.

3. Leverage Caching Layers
Tools like React Query and RTK Query prevent unnecessary requests and ensure consistent data.

4. Server-First Approach
In frameworks like Next.js, fetch data server-side whenever possible for better performance and SEO.

5. Handle Mutations with Invalidation
Always invalidate or update cached queries after a successful mutation to keep UI and server data aligned.

10. Conclusion

State management and data operations are essential parts of building efficient and scalable React applications. While React’s built-in tools like Context and hooks such as useState or useReducer can handle smaller projects, more complex applications often need advanced solutions to manage global state, server state, and API interactions efficiently.

For state management, libraries such as Redux Toolkit, Zustand provide robust and predictable ways to manage application-wide state. They help keep your logic organized and predictable, especially when multiple components need access to shared data or when actions in one part of the app affect another.

When it comes to data fetching and mutations, tools like Tanstack Query and RTK Query simplify handling asynchronous operations, caching, and synchronization between the client and server.

There are, of course, many other tools and technologies that address state management and data operations in React for example, libraries like Jotai, MobX, SWR, or even broader technologies like GraphQL that redefine how the client side communicate with the server side.

That being said, the tools covered here represent the most widely adopted solutions in modern React development and the ones I’ve personally worked with in real-world projects to deliver consistent, performant, and maintainable applications.

DEV Community: Rahman Nugar

Designing a Multi-Tenant Storefront With Wildcard Subdomains

Table of Contents

1. Giving the Storefront Its Own Identity

2. Business Names, Reserved Names, and Subdomains

3. Resolving a Storefront

4. Active and Inactive Storefronts

5. Location and Currency

6. Product Pages and Share Previews

7. Storefront Event Ingestion

8. Processing Raw Events

9. Counting Unique Visitors With HyperLogLog

10. Domain Routing and Local DNS

How Applications Stay Available During Deployment

Table of Contents

1. Restart / Recreate

2. Rolling Deployment

3. Canary Deployment

4. Blue-Green Deployment

5. Choosing the Right Deployment Strategy

6. Deployment Isn't Just About Code

How Data Access Breaks Down Under Load

Table of Contents

Idempotency Is Not Enough: Designing Deterministic Payment Systems

Table of Contents

2. What Idempotency Actually Solves

3. Why Idempotency Alone Is Not Enough

4. The Second Layer: Business-Level Uniqueness

5. Client Keys vs Server Keys

6. Retry Flows and Failure Recovery

7. Database as Final Source of Truth

8. The Design Trade-off

9. Closing Thoughts

Owlyn: Building a Multimodal Agent Ecosystem for Live Technical Interviews and Real-Time Assistance #GeminiLiveAgentChallenge

Table of Contents

1. The Core Objectives

2. System Architecture

2.1 Electron Client Layer

2.2 Backend Orchestration Layer

2.3 Worker Agent Layer

2.4 Infrastructure and AI Layer

2.5 Cross-System Communication Flow

3. The Multi-Agent Protocol

Persona Customization: Defining the Interviewer

4. Live Workflows: Interview, Monitoring, and Assistant

A. The Interview Workspace

Support for Multiple Programming Languages

B. Monitoring Mode

C. Assistant Mode

D. Practice Mode

5. Recruitment Management: Dashboards and Talent Pools

The Recruitment Dashboard

Team Collaboration

Analysis and Reporting

The Talent Pool

6. Real-Time Multimodal Pipelines

7. Security: The Sentinel Mode

8. Engineering Decisions

9. Closing Thoughts and Future Roadmap

The Owlyn Team

Code Repository

Suite 33: A business management platform for SMEs.

Table of Contents

1. Why Suite33 Was Built

2. Understanding the Challenges SMEs Face

3. Designing the Suite33 Experience

4. Getting Started: Onboarding and Setup

5. The Modules That Shape Suite33

6. Business Security and Roles

8. Lessons Learned While Building Suite33

8. Closing Thoughts

Contemporary State Management and Data Operations in React

Tools evolve, trends change.

Table of Contents

1. Understanding React’s Core State Model

2. Context API: The Native Option

3. Zustand: Lightweight Yet Scalable

4. Redux Toolkit: Predictable and Enterprise-Ready

5. useEffect: The Misused Hook

6. TanStack Query: Data Fetching Made Declarative