DEV Community: Syed Ahmer Shah

Inside the Database Stack

Syed Ahmer Shah — Wed, 07 Oct 2026 13:37:44 +0000

Think of a restaurant. Your Django code is the waiter, PostgreSQL is the kitchen, and the disk is the pantry. When dinner is slow, people blame the waiter's handwriting (the ORM). Far more often the waiter is making 200 separate trips to the kitchen, or the cook is checking every shelf in the pantry because nobody labeled them.

This article follows one order from the waiter's pad to the pantry shelf and back, and ends with what actually makes databases slow.

Part I: The Waiter (Python & Django ORM)

Django open-sourced its ORM in 2005. Its core idea is the QuerySet, a description of the data you want rather than the data itself.

orders = Order.objects.filter(status="paid")   # no SQL has run
orders = orders.filter(total__gt=100)          # still nothing
print(orders.query)                            # shows the SQL it *would* run

This is lazy evaluation. The waiter writes the order on the pad but doesn't walk to the kitchen until you actually need food: when you loop over the results, call list(), slice with a step, or ask for len(). Each .filter() returns a new QuerySet, and Django compiles the final chain into a single SQL statement only at the last moment.

That laziness is a benefit. You can build queries across functions without touching the database. It is also a trap, because a harmless-looking attribute access inside a loop can silently send the waiter running.

ORM vs raw SQL. The ORM buys you safety (parameterized queries that block SQL injection), portability, and readable code. It costs you some CPU: building the query objects, compiling SQL, and turning every row into a full Python model instance. For a few hundred rows, this overhead is invisible. For a hundred thousand rows, .values(), .only(), or .iterator() can shrink it considerably.

Part II: Too Many Trips (Query Performance)

The classic failure is the N+1 query problem:

for order in Order.objects.all():          # 1 query
    print(order.customer.name)             # +1 query per order

Show 500 orders and you've sent 501 queries. It is like a waiter walking to the kitchen 500 times for 500 glasses of water. Each trip is fast, but the trips add up, especially when the database sits across a network.

Django has two fixes:

select_related("customer") performs a SQL JOIN and fetches the related row in the same query. Use it for single-valued relations (foreign keys, one-to-one).
prefetch_related("items") runs a second query and stitches the results together in Python. Use it for many-valued relations, where a join would duplicate parent rows.

Order.objects.select_related("customer").prefetch_related("items")

Two metrics matter here, and people often confuse them. Query count is how many trips you made. Query latency is how long each one took. A page with 400 fast queries and a page with 3 slow ones need different cures. Tools like django-debug-toolbar or CaptureQueriesContext show both.

Beyond N+1, the usual bottlenecks are fetching columns you never use, calling len(qs) when qs.count() or qs.exists() would do, saving rows one at a time instead of bulk_create(), and filtering in Python what the database could filter itself.

Part III: The Pantry (Database Fundamentals)

PostgreSQL is a process-per-connection system. Each client gets its own backend process, and all of them share memory buffers and a write-ahead log (WAL), which records changes before they hit the main files so a crash can't lose them.

Rows live in a table stored as fixed-size pages, 8 KB each by default. Imagine a warehouse of unlabeled boxes. Finding "all orders from customer 42" means opening every box. That is a sequential scan, and it is the default when nothing smarter is available.

An index is the label system. The standard type is the B-tree, a balanced, sorted tree dating back to 1970. Like a phone book, it lets Postgres jump to the right place in a handful of steps instead of reading everything.

A composite index covers several columns, and order matters:

CREATE INDEX idx_orders_cust_date ON orders (customer_id, created_at);

This helps queries filtering on customer_id, or on customer_id plus created_at. It barely helps a query filtering on created_at alone, just as a phone book sorted by surname is useless for finding everyone named "Ahmed."

The key idea is selectivity: how well a value narrows the search. An index on customer_id (many distinct values) is sharp. An index on a boolean is_active where 98% of rows are true is nearly worthless, because the database would still read most of the table.

Indexes hurt, too. Every insert, update, or delete must also update every index. They consume disk and memory, and they slow writes. An index is a trade, not a gift.

Part IV: The Kitchen's Brain (Query Planning)

When SQL arrives, PostgreSQL's optimizer doesn't just run it. It considers many possible strategies, estimates the cost of each using table statistics, and picks the cheapest. Think of a GPS comparing routes.

You can ask to see the route:

EXPLAIN SELECT * FROM orders WHERE customer_id = 42;

This shows the plan and the estimated costs without running anything. Add ANALYZE and Postgres actually executes the query and reports real times and row counts:

EXPLAIN (ANALYZE, BUFFERS) SELECT * FROM orders WHERE customer_id = 42;

Careful: EXPLAIN ANALYZE really runs the statement. For an UPDATE or DELETE, wrap it in a transaction and ROLLBACK.

The plan names the access method:

Sequential scan: read the whole table. Fine for small tables, or when you need most rows anyway.
Index scan: walk the index, then fetch each matching row. Great for a few rows.
Bitmap scan: collect matching locations from the index, sort them, then read the pages in order. This is the middle path for "more than a few, fewer than most."

For joins, three algorithms compete: nested loop (for each row on the left, look up the right, good for small inputs), hash join (build a lookup table in memory, good for large unsorted inputs), and merge join (zip two sorted lists together).

The most useful habit is comparing the planner's estimated rows with the actual rows. A big gap usually means stale statistics, and ANALYZE table_name; often fixes it. The optimizer is only as good as its guesses.

Part V: Many Diners, One Kitchen (Transactions & Concurrency)

A transaction bundles steps into one all-or-nothing unit. Databases promise ACID, a term formalized in 1983:

Atomicity: all steps happen, or none do.
Consistency: rules (constraints) always hold.
Isolation: concurrent transactions don't trample each other.
Durability: once committed, it survives a crash.

PostgreSQL delivers isolation through MVCC (multi-version concurrency control). Instead of making readers wait for writers, it keeps multiple versions of a row. Readers see a consistent snapshot while writers create new versions. Readers don't block writers, and writers don't block readers. The price is cleanup: old versions pile up until VACUUM removes them.

Postgres defaults to Read Committed isolation, where each statement sees data committed before it began. Repeatable Read and Serializable are stricter, and Serializable can abort transactions with errors you must retry.

Snapshots don't stop every conflict. Take a classic race condition:

acct = Account.objects.get(pk=1)
acct.balance -= 50      # two requests both read 100, both write 50
acct.save()             # one withdrawal vanishes

The fix is to lock the row:

from django.db import transaction

with transaction.atomic():
    acct = Account.objects.select_for_update().get(pk=1)
    acct.balance -= 50
    acct.save()

select_for_update() takes a row lock, so the second request waits its turn. For simple arithmetic, an F("balance") - 50 expression pushes the math into the database itself and is even safer.

Locks bring the risk of deadlocks: transaction A holds row 1 and wants row 2, while B holds row 2 and wants row 1. It is two people in a narrow hallway, each waiting for the other to step aside. Postgres detects this (after deadlock_timeout, 1 second by default) and kills one transaction. The cure is to lock rows in a consistent order everywhere.

Part VI: How to Measure Honestly

I'm deliberately not printing benchmark numbers here. Figures from my machine would be meaningless on yours, and invented ones would be worse. What matters is the method:

Fix the environment. Same hardware, same Postgres version, same config, warm cache and cold cache runs.
Scale the dataset. Test at 1K, 100K, and 10M rows. Many problems only appear at scale, and a missing index looks harmless on a small table.
Measure several things: latency (report p50 and p95, not just the average), throughput (queries per second under concurrency), memory (tracemalloc), and query count.
Compare like with like: ORM vs equivalent hand-written SQL, and indexed vs unindexed, changing one variable at a time.

import time
from django.db import connection
from django.test.utils import CaptureQueriesContext

with CaptureQueriesContext(connection) as ctx:
    start = time.perf_counter()
    list(Order.objects.select_related("customer")[:1000])
    elapsed = time.perf_counter() - start

print(len(ctx), "queries,", round(elapsed * 1000, 1), "ms")

Run it many times, discard the first (cold) run, and keep the distribution.

Part VII: Findings

What actually causes slowness. In most web applications, the usual suspects are, in rough order of how often they appear: too many queries (N+1), missing or unusable indexes on filtered columns, fetching far more rows or columns than needed, and long-held locks. Rarely is the culprit that Python is "too slow" at building SQL.

Where the ORM is expensive. Materializing huge result sets into model instances, hidden per-row queries, and ORM-generated queries nobody has ever inspected.

Where ORM optimizations matter. select_related, prefetch_related, only()/defer(), values(), bulk_create(), exists() and iterator(). These change the shape of the work, and that is where the big wins live.

Where indexes matter. On columns used in WHERE, JOIN, and ORDER BY, in large tables, with high selectivity. Always confirm with EXPLAIN that the index is actually used.

When raw SQL is justified. Complex reporting, window functions or CTEs the ORM expresses awkwardly, or a measured hot path where the ORM's generated query is demonstrably poor. Use parameterized queries, never string formatting.

The trade-offs. Readability and safety against fine control. Fast reads against slower writes (indexes). Strict isolation against throughput.

Myths worth retiring:

"The ORM is slow." Usually the queries are slow, not the ORM.
"Raw SQL is always faster." Not if it has the same plan and the same number of round trips.
"More indexes, more speed." Each one taxes every write.
"An index will always be used." The planner may rightly ignore it.
"select_related everywhere." Joining tables you never read just makes the kitchen work harder.

The one-sentence takeaway: measure first, count your queries, read your plans, and only then optimize.

References

Find me across the web:

Portfolio: ahmershah.dev
Crunchbase: @syed-ahmer-shah
Crunchbase Company: @syedahmershah
Clutch: @syed-ahmer-shah
Tech Behemoth: @syed-ahmer-shah
Design Rush: @syed-ahmer-shah
Edverise: @syed-ahmer-shah
Trust Pilot: @ahmershah.dev
LinkedIn: Syed Ahmer Shah
GitHub: @ahmershahdev
AWS Builder Profile: @syedahmershah
DEV: @syedahmershah
Medium: @syedahmershah
Hashnode: @syedahmershah
Substack: @syedahmershah
HackerNoon: @syedahmershah
Substack: @syedahmershah
Facebook: @ahmershahdev
Linkedin Page: @syedahmershah
YouTube: @ahmershahdev
Instagram: @ahmershahdev
TikTok: @ahmershahdev

RAG Retrieval Strategies on a 50k-Document Dataset: BM25 vs Dense vs Hybrid

Syed Ahmer Shah — Tue, 06 Oct 2026 15:09:12 +0000

TL;DR

On 50k documents, retrieval quality matters more than your choice of vector database. At this size you can run exact search and skip the infrastructure.

BM25 is great at exact terms (error codes, names, IDs) and weak at paraphrases. Dense retrieval is the reverse.

Hybrid (BM25 + dense, merged with Reciprocal Rank Fusion) is the best default. It's cheap to build and covers both failure modes.

Add a reranker only after you've measured that hybrid isn't enough. Build a small eval set first, because without one you're guessing.

The setup nobody tells you about

Say you've built a RAG app over 50,000 documents: support tickets, internal docs, maybe PDFs. The demo worked. Then a real user asked a real question, and the model confidently answered from the wrong paragraph.

Nine times out of ten, the LLM isn't the problem. Retrieval is. If the right chunk never reaches the prompt, no model can save you.

One clarification before we start. "50k documents" usually means far more chunks. If each document splits into about 10 chunks, you're searching roughly 500k pieces of text. That number matters for memory and latency, so keep it in mind below.

I haven't run a fresh benchmark on your data, and I won't pretend to. This article uses published research and documented numbers to show what each approach does, where it breaks, and how to decide. If you want the background on what embeddings actually are, my post on the anatomy of AI covers vectors from the ground up.

The three contenders at a glance

	BM25	Dense	Hybrid (RRF)
Matches on	Exact words	Meaning	Both
Strong at	IDs, codes, names, jargon	Paraphrases, natural questions	Mixed real-world queries
Weak at	Synonyms, vocabulary mismatch	Rare tokens, unseen domains	Slightly more moving parts
Needs a model	No	Yes (embeddings)	Yes
Build effort	Low	Low to medium	Low, once the other two exist

BM25: the librarian with perfect index cards

BM25 is a keyword-ranking function from the 1990s. It scores a chunk higher when:

it contains your query words (term frequency),
those words are rare across the corpus (inverse document frequency), and
the chunk isn't just long and rambling (length normalization).

Analogy: imagine a librarian who never reads the books. She only keeps meticulous index cards of which words appear where. Ask for "ERR-4012" and she hands you the exact page in seconds. Ask "why does my app crash on startup" and she's stuck unless the page literally says "crash" and "startup."

Here's a minimal version using rank_bm25:

import re
from rank_bm25 import BM25Okapi

def tokenize(text: str) -> list[str]:
    # keep dots, dashes and underscores *inside* a token (ERR-4012, user_id,
    # v2.4.1) but not at its edges, so "startup." still matches "startup"
    return re.findall(r"[a-z0-9]+(?:[._\-][a-z0-9]+)*", text.lower())

tokenized_chunks = [tokenize(c) for c in chunks]
bm25 = BM25Okapi(tokenized_chunks)

def bm25_search(query: str, k: int = 50):
    scores = bm25.get_scores(tokenize(query))
    top = scores.argsort()[::-1][:k]
    return [(int(i), float(scores[i])) for i in top]

Two honest notes. First, rank_bm25 is fine for prototypes, but it scores every document per query. For production, use something with an inverted index like Elasticsearch, OpenSearch, Tantivy, or Postgres full-text search. Second, your tokenizer is half the battle. The regex above keeps ERR-4012 as one token on purpose. A default tokenizer that splits on punctuation can quietly wreck exact-match queries.

Where BM25 wins: product codes, function names, legal clause numbers, rare jargon, anything where the user types the exact words.

Where it loses: vocabulary mismatch. The user says "refund," the doc says "reimbursement." BM25 sees two unrelated strings.

Dense retrieval: the friend who gets what you mean

Dense retrieval turns text into vectors (embeddings) using a neural model. Chunks with similar meaning land close together in vector space, and you search by finding the nearest neighbors to your query vector.

Analogy: instead of index cards, you have a well-read friend. You describe a vague idea ("that thing where the server keeps retrying and makes it worse") and they say "oh, you want the doc on retry storms." They understand meaning, but they might blank on the exact serial number you asked for.

import numpy as np
from sentence_transformers import SentenceTransformer

model = SentenceTransformer("BAAI/bge-small-en-v1.5")

# 50k chunks x 384 float32 is about 77 MB. 500k chunks is about 770 MB.
doc_vecs = model.encode(chunks, normalize_embeddings=True, batch_size=64)

def dense_search(query: str, k: int = 50):
    q = model.encode([query], normalize_embeddings=True)[0]
    scores = doc_vecs @ q          # cosine similarity (vectors are normalized)
    top = np.argpartition(-scores, k)[:k]
    top = top[np.argsort(-scores[top])]
    return [(int(i), float(scores[i])) for i in top]

Notice what's missing: no vector database, no ANN index. That's deliberate.

You probably don't need an ANN index yet

Approximate nearest neighbor indexes like HNSW trade a bit of recall for speed. At small scale, you may be paying that trade for nothing. pgvector, for example, does exact nearest neighbor search by default, which gives perfect recall. Plenty of teams run tens of thousands of vectors on a plain sequential scan, and skipping the index avoids build time, maintenance cost, and the recall loss of approximate search.

If your 50k documents become 500k chunks, revisit that, but measure first. A brute-force matrix multiply over a few hundred thousand vectors is still quick on a decent machine; it's the memory (see the comment in the code above) you'll feel first. When you do need HNSW, here's the standard pgvector shape:

CREATE INDEX ON chunks
USING hnsw (embedding vector_cosine_ops)
WITH (m = 16, ef_construction = 64);

-- higher ef_search = better recall, slower queries
SET hnsw.ef_search = 100;

Always compare ANN results against exact results on your own queries before trusting the index.

Where dense wins: paraphrases, natural-language questions, cross-vocabulary matches, multilingual queries.

Where it loses: exact identifiers, rare tokens, and anything where the embedding model has never seen your domain's vocabulary.

What the research says (and what it doesn't)

The most cited evidence here is BEIR, a benchmark covering zero-shot retrieval across a wide range of settings. Its headline finding surprised people at the time. Dense models beat BM25 by a clear margin on MS MARCO, the data they were trained on, yet BM25 held up as a robust baseline almost everywhere else. The authors found dense models do well when training and target data overlap heavily, but fall short on datasets with large domain shift.

That's the key insight for your 50k-document corpus. Your data is probably not MS MARCO. It has your company's acronyms, your product names, your weird internal vocabulary. A dense model trained on generic web text is, in effect, out-of-domain. That's exactly where BM25 refuses to embarrass itself.

Two honest caveats:

BEIR is from 2021. Embedding models have improved a lot since. Don't read it as "BM25 beats dense." Read it as "dense models can fail unpredictably on unfamiliar domains, and lexical search is a safety net."
Benchmark averages hide your queries. A model can win on average and still lose on the 20% of queries your users care about most.

BEIR also showed the cost side. BM25 answers in milliseconds on a CPU, while a cross-encoder reranker on top of it was orders of magnitude slower per query in the paper's setup. Reranking helps, but it isn't free, and we'll come back to that.

Hybrid: two witnesses are better than one

Analogy: picture two witnesses to a crime. One remembers exact details (the license plate), and the other remembers the overall impression (a dark sedan, driving erratically). Either alone can mislead you. Together, they converge on the right car.

That's hybrid retrieval: run BM25 and dense search in parallel, then merge the two ranked lists.

The tricky part is the merge. BM25 scores and cosine similarities live on completely different scales, so you can't just add them. You can normalize and weight them, but the weights drift as your data changes.

Reciprocal Rank Fusion (RRF)

RRF sidesteps the scale problem by ignoring scores entirely and using only rank positions. It comes from a 2009 SIGIR paper by Cormack, Clarke, and Büttcher. The formula is one line:

RRF(d) = Σ over rankers  1 / (k + rank(d))

with k = 60 as the usual default. The paper found that value near-optimal in a pilot study, and it has stuck around ever since. Because RRF is score-independent, using only ranks, one retriever with weird score ranges can't dominate the result.

from collections import defaultdict

def rrf(ranked_lists: list[list[int]], k: int = 60) -> list[tuple[int, float]]:
    fused = defaultdict(float)
    for ranking in ranked_lists:
        for rank, doc_id in enumerate(ranking, start=1):
            fused[doc_id] += 1.0 / (k + rank)
    return sorted(fused.items(), key=lambda x: x[1], reverse=True)

def hybrid_search(query: str, k: int = 10, pool: int = 50):
    bm25_ids  = [i for i, _ in bm25_search(query, pool)]
    dense_ids = [i for i, _ in dense_search(query, pool)]
    return rrf([bm25_ids, dense_ids])[:k]

Analogy: RRF is like a talent show with two judges, where each judge only gives rankings, never scores. A contestant who is 2nd on both lists beats one who is 1st on one list and 40th on the other. Consensus beats a single loud opinion.

Two practical tips: pull a generous candidate pool (50 or so) from each retriever before fusing, and treat k = 60 as a starting point rather than a law.

A real-world data point on hybrid

Anthropic published numbers on this in their Contextual Retrieval write-up. The headline result: combining contextual embeddings with contextual BM25 cut the top-20-chunk retrieval failure rate by 49%, from 5.7% to 2.9%. They also explain why BM25 earns its place: embedding models can miss exact-match queries like unique identifiers, which BM25 handles well.

A fair caution comes from critics of that post. The best number, a 67% reduction, comes from stacking several techniques, including reranking, not from any single trick. One analysis pointed out that the headline figures measure only top-k retrieval failure rate, which may not match what you care about. So don't copy their pipeline wholesale. Take the lesson: hybrid beats either alone, and each added layer needs its own measurement.

How to actually decide: build a tiny eval

This is the part most tutorials skip, and it's the part that matters. Before you pick a strategy, write down 50 to 100 real questions with the chunk IDs that should answer them. Then measure recall@k: what fraction of the time the right chunk shows up in the top k results.

def recall_at_k(search_fn, eval_set, k=10):
    hits = 0
    for query, relevant_ids in eval_set:
        retrieved = {i for i, _ in search_fn(query)[:k]}
        hits += bool(retrieved & set(relevant_ids))
    return hits / len(eval_set)

for name, fn in [("bm25", bm25_search),
                 ("dense", dense_search),
                 ("hybrid", hybrid_search)]:
    print(name, recall_at_k(fn, eval_set, k=10))

Pull your eval questions from real user logs if you have them, and include the ugly ones: typos, error codes, vague questions. Hand-label them yourself. It's boring, and it's the highest-leverage hour you'll spend on this project.

Look at the failures, not just the number. If BM25 misses are paraphrase problems and dense misses are ID problems, you've just proven hybrid is justified for your data, not someone else's.

What I'd do on a 50k-document corpus

If I were handed this project tomorrow, here's the order I'd work in:

Start with BM25 alone. It's fast to build and a strong baseline. If it already hits your recall target, you may be done.
Add dense retrieval with a decent open embedding model, brute-force, no vector DB. Compare the two on your eval set.
Fuse with RRF. In most real corpora with mixed vocabulary, this is where recall jumps.
Fix chunking before adding fancier models. Chunks that lose their context (like a paragraph saying "it increased 12%" with no idea what "it" is) hurt both retrievers. This is the problem Anthropic's contextual approach targets.
Add a reranker last, and only if hybrid recall@50 is good but precision@5 is poor. That pattern means the right chunk is in the pool but ranked too low, which is exactly the reranker's job. Budget for the latency, since reranking can cost far more per query than the retrieval itself.
Reach for HNSW only when measurements say so, such as high query volume or a corpus that grew far past your current size.

Common mistakes I see

Skipping evaluation and trusting vibes from five hand-picked demo queries.
Tokenizing BM25 carelessly, so identifiers and code get shredded.
Normalizing and summing raw scores from different retrievers instead of fusing ranks.
Over-engineering infrastructure (a managed vector DB, three services) for a dataset whose vectors fit in under a gigabyte of RAM.
Blaming the LLM for answers that were doomed by what retrieval handed it.
Ignoring metadata filters. If users usually ask about one product or one date range, filtering before search often beats any clever ranking.

Final thoughts

There's no universally best retriever. BM25 is the reliable, literal-minded librarian. Dense retrieval is the intuitive friend who sometimes gets overconfident. Hybrid puts them in the same room and lets them check each other's work.

At 50k documents, you have the luxury of simplicity: brute-force vectors, a plain keyword index, and fusion code you can read in 15 seconds. Spend your effort on a good eval set and good chunking. Those two things will move your answer quality more than any model swap.

The snippets above are illustrative, so test them on your own data before relying on them.

References

Thakur et al. (2021). BEIR: A Heterogeneous Benchmark for Zero-shot Evaluation of Information Retrieval Models. NeurIPS Datasets and Benchmarks.
Cormack, Clarke, Büttcher (2009). Reciprocal Rank Fusion outperforms Condorcet and individual rank learning methods. SIGIR '09.
Anthropic. Introducing Contextual Retrieval.
Almond AI. Responding to Anthropic's Contextual Retrieval: Why Context is NOT All You Need.
pgvector. pgvector on GitHub.

Find me across the web:

Portfolio: ahmershah.dev
Crunchbase: @syed-ahmer-shah
Crunchbase Company: @syedahmershah
Clutch: @syed-ahmer-shah
Tech Behemoth: @syed-ahmer-shah
Design Rush: @syed-ahmer-shah
Edverise: @syed-ahmer-shah
Trust Pilot: ahmershah.dev
LinkedIn: Syed Ahmer Shah
GitHub: @ahmershahdev
AWS Builder Profile: @syedahmershah
DEV: @syedahmershah
Medium: @syedahmershah
Hashnode: @syedahmershah
Substack: @syedahmershah
HackerNoon: @syedahmershah
Substack: @syedahmershah
Facebook: @ahmershahdev
Linkedin Page: @syedahmershah
YouTube: @ahmershahdev
Instagram: @ahmershahdev
TikTok: @ahmershahdev

One Seat, Two Buyers: Race Conditions, IDOR and Keys in a Cinema Booking System

Syed Ahmer Shah — Tue, 06 Oct 2026 15:08:35 +0000

Seat G7 at the 9 PM show. Two people have it open on their phones. Both tap it, both see it turn yellow, both press Confirm within the same half-second.

Exactly one of them should get a ticket. The other should see "that seat was just taken, here are the two next to it". Not an error page, not a refund e-mail tomorrow, not two people in the lobby holding the same seat.

I built BookMyMovie, a cinema booking platform, on my own with Laravel, React and MySQL. This is how it handles the moments where people collide, what it does about the quieter security problems (guessable IDs, secret keys, bots), and the bugs that still got through.

Why "check, then insert" is wrong

The obvious code looks like this:

// Looks fine. Isn't.
if (Seat::isAvailable($showId, $seatId)) {
    BookingSeat::create(['show_id' => $showId, 'seat_id' => $seatId, ...]);
}

Two requests run the if at the same moment. Both see "available", because neither has inserted anything yet. Both insert. You've sold the seat twice, and no test that runs one request at a time will ever notice.

Every fix below is a different way of making "check" and "act" one indivisible step.

Layer 1: row locks, always in the same order

Holding seats and checking out both run inside a transaction that starts by locking rows with SELECT … FOR UPDATE:

DB::transaction(function () use ($seatIds, $data) {
    // 1. The customer: serialises this person's double clicks and second tab.
    User::query()->whereKey(Auth::id())->lockForUpdate()->firstOrFail();

    // 2. The show: everyone buying seats for this show now queues here.
    $show = Show::query()->lockForUpdate()->find($data['show_id']);

    // 3. The seats themselves, then 4. the cart.
    Seat::query()->whereIn('id', $seatIds)->lockForUpdate()->count();
    $cart = Cart::query()->where('user_id', Auth::id())->lockForUpdate()->first();

    // Only now: is every seat still available?
    // ...insert the holds...
}, 3);

Two details carry most of the weight.

The order never changes. Adding seats and checking out, the two paths that race for the same seats, take user, then show, then seats, then cart. The shorter paths take fewer locks but never reverse that order: removing a seat locks only the cart, and cancelling locks the booking and then the show, which nothing locks the other way round. If one request locked the show and then the cart while another locked the cart and then the show, each could end up holding the lock the other needs, and MySQL would have to kill one. With one order everywhere, the second request just waits its turn.

The 3 at the end retries the whole transaction up to three times if MySQL still reports a deadlock (it can, under odd index-gap locking). The customer never sees it.

The snapshot trap I checked for

MySQL's default isolation level, REPEATABLE READ, has a trap I wrote about in The Last Mango Problem: a plain SELECT inside a transaction reads from a snapshot taken at the transaction's first plain read, not from the latest data. If that snapshot is taken before you wait for a lock, you can wait patiently for the other buyer to finish and then read a picture of the world from before they bought the seat.

In BookMyMovie the availability check reads a view, v_seat_availability, with a plain SELECT. It's safe here only because of when the snapshot is taken. The locking reads at the top (FOR UPDATE) don't create a snapshot. The first plain read happens after the show lock is held. And every transaction that sells a seat for this show must hold that same show lock, so by the time we read, any competing sale has either committed (and is in our snapshot) or hasn't started. Move one innocent-looking exists() query above the show lock and that guarantee is gone. That is exactly why the next layer exists.

Layer 2: a unique key that tolerates NULL

Locks are code, and code has bugs. So the database has the final word:

UNIQUE KEY booking_seats_live_seat_unique (show_id, seat_id, seat_lock)

seat_lock is 1 while a ticket is live and NULL once the booking is cancelled. In MySQL a unique index allows any number of rows that contain NULL. So:

a cancelled ticket (seat_lock = NULL) doesn't block the seat being sold again;
a second live ticket for the same seat at the same show is impossible, whatever the PHP does.

I have a test that skips every check in the application and inserts the duplicate row directly. MySQL throws, and the test passes only when it does. The cart has the same kind of guard, UNIQUE (seat_id, show_id) on cart_items, so two carts can't hold one seat either.

Layer 3: idempotency for the double tap

Networks retry. People double-tap. A slow checkout gets a second press of Confirm. Each checkout form carries a UUID generated when the page loads:

if ($existing = Booking::query()
        ->where('idempotency_key', $data['idempotency_key'])
        ->where('user_id', Auth::id())
        ->first()) {
    return redirect()->route('user.booking.show', $existing->booking_number);
}

bookings.idempotency_key is unique, so even two submits that both pass this check at the same instant can't both insert: the second fails on the key and the customer lands on the booking the first one made.

Layer 4: status locks, so nothing is refunded twice

The cancellation path had a hole I found while writing tests for it. A customer cancels from the app while an admin refunds the same booking from the back office. Both callers locked the booking and checked "is it still confirmed?", but that check lived in each caller, not in the code that does the unwinding. Any future caller that forgot it (a scheduled job, a new admin button) could run the unwind a second time: seats released twice, the coupon returned twice, the gift card refilled twice.

So the booking's status now moves through a compare-and-set:

public const STATUS_TRANSITIONS = [
    'confirmed' => ['completed', 'cancelled', 'no_show'],
    'completed' => [], 'no_show' => [], 'cancelled' => [],
];

public function claimStatus(string $status, array $extra = []): void
{
    $from = (string) $this->booking_status;

    if (! $this->canMoveTo($status)) {
        throw new StaleStatusException("Cannot move from {$from} to {$status}.");
    }

    $claimed = static::query()
        ->whereKey($this->getKey())
        ->where('booking_status', $from)          // only if nobody changed it
        ->update(['booking_status' => $status, ...$extra]);

    if ($claimed !== 1) {
        throw new StaleStatusException('Changed while it was being updated.');
    }
}

BookingLifecycle::unwind() calls claimStatus('cancelled', …) first, before it touches a single seat or balance. If the row isn't confirmed any more, the UPDATE matches nothing, the exception rolls the whole transaction back, and nothing is refunded. The test for it cancels a booking, then tries again with a stale copy of the model that still says "confirmed". It must be refused, and the show's sold count must not move.

The same guarded-update idea appears in smaller places: "tell the watchlist this film is open for booking" is claimed with UPDATE … WHERE booking_opened_notified_at IS NULL, so it happens exactly once even if two admins save the film at the same moment, and the show's sold count is only lowered WHERE booked_seats >= n, so it can never go negative.

Layer 5: locks that live outside the database

When seats come back (a cancellation, or a 10-minute hold that ran out), a job tells that show's waitlist, first come, first served. The scheduler sweeps every minute and a cancellation dispatches the job straight away, so the same show's job was often queued twice.

class ProcessShowWaitlist implements ShouldBeUnique, ShouldQueue
{
    public int $uniqueFor = 120;

    public function uniqueId(): string { return (string) $this->showId; }

    public function middleware(): array
    {
        return [(new WithoutOverlapping('show-'.$this->showId))->releaseAfter(10)->expireAfter(120)];
    }
}

ShouldBeUnique drops a second dispatch while one is waiting; WithoutOverlapping stops two workers running the same show at once. Both use atomic cache locks, not database rows. Inside the job, the waitlist rows are still locked with FOR UPDATE and each person is marked notified in the same transaction, so nobody gets two "seats just opened" pushes.

The home page's cached rails use the same idea against a different problem. With Cache::remember, the moment the cache expires every visitor rebuilds it at once (a cache stampede). Cache::flexible keeps serving the stale copy while exactly one request, holding a lock, rebuilds it.

IDOR: the booking number is not a password

Insecure Direct Object Reference is the bug where changing an ID in the URL shows you someone else's data. Booking numbers look like BM-2026-7KQ2X9TD. They're random, but "hard to guess" is not access control, because booking numbers get screenshotted, forwarded and printed.

So every customer-facing lookup is scoped to the person asking:

private function userBooking(string $number): Booking
{
    return Booking::query()
        ->where('user_id', Auth::id())   // the whole point
        ->where('booking_number', $number)
        ->firstOrFail();                 // someone else's booking: 404, not 403
}

It returns 404 rather than 403 on purpose: a 403 would confirm the booking exists. A test signs in as a second customer and tries to view and cancel the first customer's booking; both must 404.

The places that have to work without an account get a different treatment:

Thing	How it's protected
Split-the-bill share links	A 40-character random token per share, unique in the database. Knowing the booking number gets you nothing
Ticket QR codes	The booking number plus an HMAC-SHA256 signature over it, keyed with the app key. The box office recomputes it and compares with `hash_equals()`, so an edited booking number fails
Gift card balance check	The code is random (`BMM-XXXX-XXXX`), and the endpoint is limited to 10 checks a minute
Admin member pages	Numeric IDs, but only reachable by signed-in staff, and every admin route maps to a role; routes missing from the map require the highest one

That last point is the rule I'd pass on: authorisation should fail closed. In BookMyMovie's admin, a new route that nobody remembered to classify needs the highest role, instead of being open to every staff account.

Keys: what breaks when a secret moves

Most security incidents in small apps aren't clever. They're a key in the wrong place or a key that changed. Things I learned the hard way in this project:

APP_KEY does more than encrypt sessions. It signs every ticket QR code and encrypts staff two-step secrets. Rotating it invalidates every ticket already issued and locks every staff member out of 2FA. That's written down in the security policy now, not just in my head.
Truncating a signature is a trade-off. The ticket signature is the first 16 hex characters (64 bits) of the HMAC, to keep the QR code small enough to scan quickly in a dark lobby. That's plenty against guessing, because checking a signature needs a staff session, but I'd rather say it out loud than pretend 64 bits is 256.
Keys belong in .env only. reCAPTCHA, JazzCash, Easypaisa, wallet certificates and the web-push VAPID pair are read from configuration and nowhere else. On XAMPP for Windows, generating VAPID keys failed until OpenSSL was pointed at its config file; the command that generates them now sets that itself.
Timing is a leak too. When an admin e-mail doesn't exist, the login still hashes a throwaway password, so "unknown e-mail" and "wrong password" take the same time and don't reveal which staff accounts exist.

When adding keys added a bug

The most embarrassing key problem was the opposite of a leak. With no reCAPTCHA keys, local development used Google's public test keys and everything looked fine. When the real v2 and v3 keys went in, every form showed the v2 checkbox and v3's floating badge, and the server demanded both tokens. Two captchas on a login form is a great way to lose customers.

The redesign: when a v3 key exists, v3 runs invisibly on every submit and the checkbox is hidden. If v3's score is too low, or its token didn't load, the server remembers that for this form in the session and fails with "one more check". The next render shows the checkbox, and that submit is judged by the checkbox alone. One Google check at a time, and the stricter one only for traffic that earned it.

What still got through

Everything above is about data. The worst bug I shipped in this project had nothing to do with data.

The seat map page and the lazy-loaded 3D model of the hall both imported one small geometry file. In a production build, Rollup merged that file into the seat map's own chunk, which made the page a "shared chunk" with no entry of its own in Vite's manifest. Laravel looks pages up in that manifest by name, so every visit to the seat map (the page every booking goes through) returned a 500. The development server builds nothing ahead of time, so it never showed up there. All the locks in this article were protecting a page nobody could open.

I found it while taking screenshots for these articles, fixed it by giving the shared file its own chunk, and added a test that fails if any page is missing from the manifest. The general lesson: your concurrency tests are only as good as your deployment tests. A race-proof checkout behind a broken build is still a broken checkout.

The checklist I'd use again

Put every "check, then act" on money, seats or stock inside one transaction with FOR UPDATE.
Take locks in one documented order everywhere, and retry deadlocks.
Make the database refuse the impossible state (UNIQUE with a nullable column is a neat trick for "at most one live row").
Give every submit an idempotency key with a unique index.
Move statuses with compare-and-set, and put the allowed transitions in one place.
Use atomic cache locks for jobs and caches that more than one process can run.
Scope every lookup to its owner and return 404 for someone else's object.
Sign anything you hand out that can't be scoped (tickets, share links), and compare signatures in constant time.
Write down what each secret signs or encrypts before you ever rotate it.
Test the build you deploy, not just the code you wrote.

The code, including the tests that try to sell one seat to two customers and to cancel one booking twice, is on GitHub. The case study covers the rest of the project: the stack, design, SEO and what I'd change.

Find me across the web:

Portfolio: ahmershah.dev
Crunchbase: @syed-ahmer-shah
Crunchbase Company: @syedahmershah
Clutch: @syed-ahmer-shah
Tech Behemoth: @syed-ahmer-shah
Design Rush: @syed-ahmer-shah
Edverise: @syed-ahmer-shah
Trust Pilot: ahmershah.dev
LinkedIn: Syed Ahmer Shah
GitHub: @ahmershahdev
AWS Builder Profile: @syedahmershah
DEV: @syedahmershah
Medium: @syedahmershah
Hashnode: @syedahmershah
Substack: @syedahmershah
HackerNoon: @syedahmershah
Substack: @syedahmershah
Facebook: @ahmershahdev
Linkedin Page: @syedahmershah
YouTube: @ahmershahdev
Instagram: @ahmershahdev
TikTok: @ahmershahdev

BookMyMovie: Building a Cinema Ticketing Platform

Syed Ahmer Shah — Tue, 06 Oct 2026 15:07:51 +0000

Buying a cinema ticket in Pakistan still often means calling the cinema, queueing at the counter, or using a site that shows you a seat map, lets you pick a seat, and then tells you at the last step that somebody else already has it. Prices are rarely clear before you commit, premium screens (IMAX, Dolby, recliners) are hard to compare across cinemas, and the ticket is usually a screenshot you hope the usher will accept.

BookMyMovie is my answer to that. It started as my Aptech DISM project in July 2026 and ended up as a full platform that I designed and built alone: the research, the UI, the database, the backend, payments, security, SEO, the admin back office, tests and documentation. You browse films, watch trailers, pick seats on a live map (or from inside a 3D model of the hall), add snacks, book, and get a signed QR e-ticket that still opens with no signal.

This is how it's put together, what went wrong, and what I'd change.

The one rule

"Never sell the same seat twice, and never show a price you won't charge."

A shop can apologise for a late parcel. Two people holding tickets for G7 at the 9 PM show is a scene in the lobby. Almost every design decision below comes back to that sentence.

Who uses it

Moviegoers browse films and cinemas, watch trailers, compare up to four films, pick seats, mix adult and child tickets, add snacks, apply a coupon, a gift card or loyalty points, and pay online or at the counter. They get a QR e-ticket (with Apple and Google Wallet passes when configured), a watchlist, a waitlist for sold-out shows, a way to split the bill with friends, and "verified booking" reviews.
Box-office staff scan tickets at the door, refund bookings, issue gift cards and look up members.
Managers and the owner run films, showtimes, row prices, coupons, snack stock, reviews, bans, site settings and SEO, and read revenue and occupancy reports. Three roles (owner, manager, box office) are enforced on every admin route, with authenticator-app two-step sign-in.

Choosing the stack

I wanted an interface that feels like an app, with no full page reloads, and a backend where routing, authentication and validation stay on the server where I can reason about them.

Laravel 12 and React 19, joined by Inertia 2, gave me both. Every page is a React component, but there's no public JSON API to secure. A controller validates the request, checks who is asking, and hands props to the page. The layout never unmounts, so the navbar, the seat-hold countdown and the assistant survive navigation.

Layer	Choice	Why
Backend	Laravel 12, PHP 8.2	Routing, Eloquent, queues, rate limiting, mail
Bridge	Inertia 2 + Ziggy	SPA navigation with server-side routing and auth
Frontend	React 19, strict TypeScript, Tailwind CSS 4	Components, one set of design tokens for two themes
Motion and 3D	Motion, Lenis, Three.js via @react-three/fiber	Page motion, smooth scroll, the poster ring and the 3D hall
Database	MySQL 8 / MariaDB	Foreign keys, unique guards, reporting views, row locks
Payments	JazzCash, Easypaisa, card, pay at counter	What people in Pakistan actually use
Mail and jobs	Resend, database queue	E-mail never blocks a page

Architecture

The rule I kept coming back to was thin controllers, and one class for every set of rules that must hold together. Cancelling a booking is a good example. It has to put the seats back on sale, lower the show's sold count, return the coupon use, refill the gift card, reverse the loyalty points, update the payment and tell the waitlist. A customer cancelling from their phone and an admin issuing a refund go through the same BookingLifecycle::unwind(), so the two can never drift apart.

Other decisions that paid off:

One source of truth per concern. App\Support\Seo builds titles, Open Graph and JSON-LD for every page. App\Support\MovieMedia links artwork and trailers by the film's slug, so adding a trailer is "drop three files in a folder and run a migration".
Anything slow goes on the queue. Receipts, waitlist alerts and web push are jobs, retried on failure.
The scheduler does the boring, important work: expiring 10-minute seat holds every minute, sweeping waitlists and draining the queue where no long-running worker exists.

The data model

The schema is 56 tables and 9 reporting views. The shape is simple once you see it: a city has theaters, a theater has screens, a screen has seats. A show is one film on one screen at one time. A customer's cart holds seats for ten minutes; checkout turns it into a booking with one booking seat per ticket.

What makes it trustworthy is what the database itself refuses:

shows (screen_id, show_date, show_time) is unique: two films can't be scheduled on the same screen at once.
cart_items (seat_id, show_id) is unique: a seat can sit in only one cart.
booking_seats (show_id, seat_id, seat_lock) is unique, and seat_lock is 1 while a ticket is live and NULL once it's cancelled. MySQL lets a unique index hold any number of NULLs, so a cancelled seat can be sold again, but no bug, script or admin can ever insert a second live ticket for the same seat. I have a test that bypasses every piece of PHP and inserts the row by hand; the database throws.
bookings.idempotency_key is unique: a double-tapped "Confirm" returns the booking it already made.
reviews (user_id, movie_id) and show_waitlists (show_id, user_id) are unique: one review per film, one waitlist place per show.

The reporting views (v_seat_availability, v_show_details, v_daily_revenue and six more) keep the seat map and every dashboard chart down to a single query each.

Booking a seat

Every booking starts from a film's showtimes: one row per cinema, the lowest seat price on each show, the matinée discount in red and a warning once a show is more than 60% sold.

Pick seats. Each row has its own price (front rows cheapest, "Prime Centre" best, recliners at the back), weekday shows before 5 PM carry a 15% matinée discount, and child tickets are about 25% cheaper (not on recliners). "Best 2 together" finds adjacent seats near the centre, about two-thirds of the way back.
Hold. Adding seats to the cart runs one transaction: lock the customer, then the show, then the seats, then the cart, check availability, insert the holds. The seats are yours for ten minutes, with a countdown in the navbar.
Check out. The same lock order again. Prices, coupon limits, gift card balance and points are all re-checked inside the transaction, never trusted from the browser.
Ticket. The booking gets a QR code carrying an HMAC signature, so the box office can tell a real ticket from an edited one.

Coupons have their own page, with the minimum spend, the cap and the end date printed on each one, so the discount at checkout is never a surprise.

The fixed lock order (user → show → seats → cart) matters as much as the locks. Two requests that take the same locks in a different order can each hold one lock and wait forever for the other. Taking them in one order everywhere means one request simply waits for the other to finish. Deadlocks that still happen are retried up to three times.

I wrote a separate article about the concurrency and security side, including the bugs: One seat, two buyers: race conditions, IDOR and keys in BookMyMovie.

The back office

The admin side is where most of the day-to-day work happens, so I rebuilt it around one question: "what does this person need to do right now?" The sidebar is grouped by job (Today, Catalogue, People, Reports, Settings), every item has a one-line hint, and every page opens with a short "How this page works" guide that can be tucked away once you know it.

The overview answers "is tonight going well?" at a glance. The timeline gives each screen its own lane and fills each show's bar by the share of seats sold, with a red line for the time right now. A "Needs you" list links straight to the unpaid bookings and unread messages that want a person.

Editing a film is a numbered form (basics, price and rating, artwork, home carousel, search engines) with one save bar that says whether anything is unsaved. Every input shows an example value, so nobody has to guess what "slug" means.

Refunds are one button. Behind it, the same BookingLifecycle::unwind() a customer's cancellation uses puts the seats back on sale and returns the coupon use, gift card balance and loyalty points, and the customer is e-mailed.

Three roles decide who sees what: the owner can do everything, a manager runs films, prices, coupons, members and refunds, and box-office staff see the dashboard and bookings and check tickets at the door. Each person's two-step status is visible at a glance, and banning a member also blocks every IP and browser they used.

Taking these screenshots found two layout bugs I had missed: a shared form-field style that stretched labels away from their inputs whenever a row was taller than the field, and a staff table that cut off its last column. Both are fixed; the first was one line of CSS (align-content: start) that tidied every form on the site.

Design

The design brief I set myself was "cinema signage": near-black ink, warm paper, and one electric volt accent, with condensed, variable-width Archivo capitals the way a marquee spells a title. Geist Mono carries anything that is data (times, prices, booking numbers). Edges are hard; the only curves are the screen on the seat map.

A few pieces I'm proud of:

Trailers everywhere. Short silent trailers play behind the home carousel and film pages, with a WebP still first. They only autoplay when motion is allowed, Data Saver is off and the connection is faster than 3G.
See it from your seat. A Three.js model of the hall: sit in any seat, watch the trailer on the screen as the lights dim, and get a view score (distance, how much of your view the screen fills, off-centre angle and neck tilt).
Two themes, one set of tokens. Every colour is a CSS variable, and dark and light themes redefine them. Both pass WCAG AA contrast. They didn't at first (more on that below).
Urdu. A full English/Urdu switch with a right-to-left layout and Noto Naskh Arabic. Film titles, prices and booking numbers stay in Latin script so they match the ticket in your hand.
Usher. A small assistant that answers preset questions ("cheapest seat tonight?", "where can I watch in IMAX?") from live listings. Signed-in customers get personal answers: their next show, their points, which watchlist films are on sale, and a pick based on the genres they book. It has no free-text box on purpose: nothing a visitor types is ever sent anywhere.

On a phone the whole thing collapses to one column without a single sideways scroll, from 320 px up. I check that with a script rather than by eye.

SEO, and search for AI

Inertia renders the page body in the browser, so the server has to do the rest of the work for crawlers:

Server-rendered head. Every page's title, description, canonical URL, Open Graph image (generated per film, 1200×1200) and robots rule come from the controller and are written into the HTML before any JavaScript runs.
JSON-LD. Organization, WebSite with a search action, BreadcrumbList, and for each film a Movie with its cast, rating and every upcoming ScreeningEvent with offers.
A generated sitemap (64 URLs with film images) and llms.txt / llms-full.txt, a plain-text description of the site and its whole catalogue for AI assistants, regenerated from the database with php artisan seo:generate.
Deliberate noindex. Search results, password reset and the admin area are kept out of search engines. Lighthouse marks those pages down for it, and I accept that.

Lighthouse's accessibility, best practices, SEO and agentic-browsing categories score 100 on every public page (the noindex pages lose SEO points by design, and admin login loses a few best-practice points to Google reCAPTCHA's own iframe).

Security

Area	What protects it
Passwords and sign-in	Argon2id; optional e-mailed 6-digit codes for customers; authenticator-app TOTP with recovery codes for staff; sessions regenerated on sign-in
Access control	Every customer query is scoped to the signed-in user, so a guessed booking number is a 404; admin roles are mapped per route and anything not in the map needs the highest role (it fails closed)
Bots	Honeypot, minimum fill time, a server-drawn single-use image code, invisible reCAPTCHA v3 with the v2 checkbox only as a step-up, rate limits, and bans that cover the account, every IP and every browser it used
Browser	Nonce-based Content-Security-Policy, HSTS, `X-Frame-Options: DENY`, CSRF on every form
Payments	Amounts recomputed on the server; JazzCash callbacks verified by signature and amount before anything changes; payment and booking rows locked while settling
Tickets	HMAC-signed QR payloads, checked with a constant-time comparison at the door
Uploads	Re-encoded to WebP, which also strips EXIF and GPS data
Audit	Every data-changing action by staff and customers is logged with before and after values

Performance and caching

Images ship in two sizes (card-sm.webp 640 px and card.webp 1200 px) with srcset, explicit dimensions and lazy loading. The server tells the browser to preload the one image that is the largest paint, plus the two text fonts. Converting the original artwork from PNG to WebP took it from about 85 MB to 5.4 MB.
Trailers are VP9 WebM first with an H.264 MP4 fallback. The latest one went from 3.4 MB to 1.1 MB.
Five cache layers: HTTP (hashed assets cached for a year, film art for a month), the service worker (offline tickets, stale-while-revalidate film art), the application cache (home rails and menus served stale while one request rebuilds them under a lock, so an expiry never stampedes the database), a per-request memo, and the database views.

Where it broke

This is the part I'd want to read in someone else's case study.

The seat map returned a 500 in production builds. The seat map page and the lazy-loaded 3D hall both imported a small geometry file. Rollup quietly merged that file into the page's own chunk. The page then had no entry of its own in Vite's manifest, and Laravel answered every visit to the most important page on the site with "Unable to locate file in Vite manifest". Development mode hid it completely. I found it while taking screenshots for this article. The fix was one line (give the shared file its own chunk). The lesson was a test that checks every page is in the manifest, which now runs with the others.

The service worker never installed. It pre-cached four files with cache.addAll(), one path was wrong, and addAll rejects the whole batch if any one file fails. So offline tickets, the feature I talk about most, silently didn't work, and the only symptom was an "Uncaught (in promise)" in the console. Now each file is cached on its own and a missing one is skipped.

Two captchas at once. When the real reCAPTCHA keys went in, forms showed the v2 checkbox and v3's floating badge, and the server required both. I redesigned it: v3 runs invisibly on every submit, and the checkbox appears only as a step-up when v3's score is too low or it fails to load.

Unreadable buttons. The selected "Newest / Most helpful / Highest / Lowest" chip got a light background from one rule and accent-coloured text from another. In the dark theme that was volt on off-white; in the light theme it was olive on near-black. Both were unreadable. The quietest grey text was also below 4.5:1 contrast. I fixed the tokens, not the individual screens.

Phones scrolled sideways. A CSS grid with no column template sizes its one column to its widest content, so on the FAQ a row of category buttons made the page 968 px wide on a 375 px phone. The shared grid component now defaults to minmax(0, 1fr), and a script loads every page at 320, 375, 414, 768 and 1024 px and fails if anything scrolls sideways.

Old links 404'd. Seat maps moved from /movies/{film}/{show} to /movies/{film}/book/{show}, and bookmarked or shared links broke. They now redirect permanently.

Downsides I'd be honest about in a review

No server-side rendering of the page body. The head, JSON-LD and sitemap cover search engines well, but a crawler that doesn't run JavaScript sees an empty body. Inertia SSR would fix that at the cost of a Node process on the server.
Mobile performance is the weak score. Lighthouse performance on a throttled phone is low on the film pages: Three.js, a trailer and two variable fonts are a lot for a mid-range phone. The 3D scenes are lazy and skipped on slow connections, but the first load is still heavy.
One door for most admin writes. Many admin forms post to a single endpoint with an _action field. The role check maps each action to a permission and fails closed, but a single dispatcher is harder to audit than one route per action.
"Set the rating by hand." The admin can show a hand-set star rating for launch week. It's clearly labelled internally, but it's the kind of feature that becomes a dark pattern in the wrong hands. In a real deployment I'd remove it.
Short ticket signatures. The QR carries 64 bits of an HMAC-SHA256 (16 hex characters) to keep the code small enough to scan quickly. Guessing one means brute-forcing an endpoint only staff can reach, but it's still a trade-off, not a free lunch.
Payments are sandbox-only. The JazzCash and Easypaisa flows, signatures and refunds are built and tested, but no real money has moved through them.
Tests stop at the server. 38 PHPUnit feature tests cover booking, payments, bans, roles, waitlists and group bookings on a real MySQL database, and I use scripted Lighthouse and headless-Chrome checks for the front end. There are no committed end-to-end browser tests yet.

Where it stands

BookMyMovie is finished as a portfolio project. It isn't hosted anywhere; the code lives on GitHub, archived, with everything needed to run it locally in one migrate --seed. If I picked it up again for a real cinema, this is the order I'd work in:

Turn on Inertia SSR and measure the phone performance again.
Replace the admin dispatcher with one route per action.
Add Playwright end-to-end tests for "two people, one seat" in two real browsers.
Move cache, sessions and the queue to Redis and put the media behind a CDN.
Go live with one partner cinema and real payments.

What it taught me

The interesting work in a booking system isn't the booking form. It's the half-second where two people press "Confirm" on the same seat, the payment callback that arrives twice, the admin who refunds a booking the customer is cancelling at the same moment, and the build tool that quietly moves your page into the wrong file. Most of what I'm proud of in BookMyMovie is invisible when it works.

The code is on GitHub under the MIT licence (archived, read-only), with the full data model, locking and caching design and every screen in the README.

Find me across the web:

Portfolio: ahmershah.dev
Crunchbase: @syed-ahmer-shah
Crunchbase Company: @syedahmershah
Clutch: @syed-ahmer-shah
Tech Behemoth: @syed-ahmer-shah
Design Rush: @syed-ahmer-shah
Edverise: @syed-ahmer-shah
Trust Pilot: @[ahmershah.dev]
LinkedIn: Syed Ahmer Shah
GitHub: @ahmershahdev
AWS Builder Profile: @syedahmershah
DEV: @syedahmershah
Medium: @syedahmershah
Hashnode: @syedahmershah
Substack: @syedahmershah
HackerNoon: @syedahmershah
Substack: @syedahmershah
Facebook: @ahmershahdev
Linkedin Page: @syedahmershah
YouTube: @ahmershahdev
Instagram: @ahmershahdev
TikTok: @ahmershahdev

The Discount That Knew You Were Hesitating: Rule-Based Personalisation in an Online Pharmacy

Syed Ahmer Shah — Tue, 06 Oct 2026 15:07:50 +0000

You open a cough syrup on a pharmacy site. You read the dosage, check the price, close the tab. Two days later you're back on the same page. Then again that evening.

A good pharmacist behind a counter would notice. They'd say "still thinking about that one? I can do it a bit cheaper." Most online stores don't notice anything, or they notice in the creepiest possible way: an ad for the same syrup following you around the internet for a month.

I built Zovita+, an online pharmacy, on my own with Laravel, React and MySQL. One of the things I wanted from it was a store that notices like the pharmacist does: quietly, inside the store, with offers that are small, time-limited and explainable. This is how that works, why it's rules and not a model, and where the hard parts actually were. Spoiler: the hard part was never deciding on the discount. It was making sure the customer is charged exactly what they were shown, exactly once.

Why rules, not a model

The first question people ask is "is it AI?". It isn't, on purpose.

A pharmacy is a bad place for a black box. If a customer asks "why did I get 8% off this?", the answer has to be a sentence, not a feature-importance chart. If a pharmacist asks "could this ever discount something by 40%?", the answer has to be "no, and here is the line of code that stops it". And with a few hundred test shoppers, there is no data to train anything on.

So the store learns in the plainest possible way: it counts things, and a handful of rules turn those counts into offers. Every offer carries the reason in plain words ("You've been looking at Prospan Cough Syrup 120Ml"), and the whole system is about 400 lines of PHP with seven tests.

Step 1: one key for everyone

Personalisation has to work for guests, because most people browse a pharmacy without signing in. So the first piece is a Visitor service that gives every request a single string:

u:42 when someone is signed in, or
g:9f1c… for a guest, from a UUID in a long-lived, HTTP-only, first-party cookie (zv_vid).

Every table that personalises (product_interactions, offers, experiment_events) stores that string in a visitor column, with user_id alongside it when there is one. Nothing downstream needs to care whether the visitor is signed in. They just ask $visitor->key().

The cookie is first-party, set by the store itself, and never shared with anyone. That is the line between "the shop remembers you" and "the internet follows you".

Step 2: count, don't track

product_interactions has one row per visitor and product, with four counters and two timestamps:

Column	Bumped when
`views`	the product page is opened
`dwell_seconds`	the page reports how long it was actually visible
`cart_adds`	the product goes into the bag
`purchases`	an order containing it is placed
`last_seen_at`, `last_purchased_at`	the last view and the last purchase

Dwell time comes from the browser: the product page measures how long it was visible (not just open in a background tab) and posts it to /signals/dwell. That endpoint is the one place where the client gets a say, so it gets the least trust. The product must exist, the seconds must be an integer, the route has its own rate limit, and anything above 600 seconds is clamped. One report can never be worth more than ten minutes of attention, so a tab left open overnight, or a script posting huge numbers, can't push a product over the "you've been looking at this" line on its own.

There is deliberately nothing else in that table. No referrer, no search terms, no list of pages in order. Counters are enough for the rules, and data you don't store can't leak.

Step 3: six rules

OfferEngine reads the counters and creates offers. The whole rulebook fits in a table:

Rule	When	Offer
hesitation	viewed 3+ times, or 45+ seconds in total, without buying	8% on that product, 72 hours
cart rescue	added to the bag more than a day ago, never bought	5% on that product, 48 hours
regular	bought 2+ times	10% on that product, 7 days
welcome	signed up in the last 60 days, no orders yet	5% off the order, 14 days
loyalty	3+ orders (8+ for the bigger one)	5% or 10% off the order, 30 days
comeback	has ordered, but not in 45 days	7% off the order, 10 days

The rules are the easy part. The interesting code is the set of guards around them, each of which exists because of a case I could picture going wrong:

Never duplicate a live offer. Before creating anything, the engine loads the visitor's live offers and skips a rule whose offer already exists for that product. Otherwise every visit would mint a fresh 8% coupon.
At most four product offers at a time. Someone who opens forty products shouldn't get forty discounts. The engine walks products in order of dwell time, so the four they lingered on longest win.
Only in-stock products with a real photo. An offer on something sold out is a tease, and an offer card with a placeholder image looks broken.
A cool-down after redemption. If you just bought something with an offer, you don't get another offer on it for 14 days. Without that, "hesitation" would fire again on your next visit and teach you to wait for a discount.
Throttled evaluation. Running the rules on every request would be wasteful, so evaluate() takes a cache lock (Cache::add) that expires after five minutes and returns early if it's already taken. Placing an order or signing in clears that, so the rules re-run when something important has changed.

Step 4: one function prices both the bag and the charge

This is the part I'd tell anyone building discounts to copy.

There are two moments when a discount is calculated: when the customer looks at their bag, and when the order is created. If those are two different pieces of code, they will drift. Someone will add a cap to one and forget the other, round differently, or apply the order-wide discount before the product discount in one place and after it in the other. Then the bag says one total and the receipt says another, which is exactly what I promised myself would never happen.

So there is exactly one function, Pricing::apply($lines, $offers), and both moments call it:

Each line gets the best live offer for that product.
The best order-wide offer then applies to what's left.
The total personal discount is capped at 15% of the payable amount.

The cap lives in that function and nowhere else, as Pricing::MAX_SHARE = 0.15. A "regular" 10% plus a "loyalty" 10% could add up to 19%; the cap brings it back to 15%. There is a test for exactly that ("stacked offers are capped"), and another that places an order and checks the charged total equals what the bag showed.

Step 5: redeem it once, under a lock

Now the concurrency problem. An offer is a small amount of money with a "use once" rule attached, which means two browser tabs can race for it.

Picture it: the customer has the bag open in two tabs and presses Place order in both. Without care, both checkouts read the same live offer, both apply it, both create an order, and both mark it redeemed. The discount was used twice.

In Zovita+, offers are handled inside the same database transaction that locks stock:

$offers = Offer::where('visitor', $visitor)->active()->lockForUpdate()->get();
$personal = Pricing::apply($lines, $offers);
// … create the order with $personal['discount'] …
Offer::whereKey($personal['used'])->update(['redeemed_at' => now(), 'order_id' => $order->id]);

lockForUpdate() means the second checkout waits at that line until the first one commits. When it gets the rows, the first checkout has already set redeemed_at, so the active() scope (not expired, not redeemed) no longer returns that offer and the second order is priced without it. (Each checkout page also carries its own one-time token under a unique index, which stops a double-click in one tab from creating two orders. Two tabs have two different tokens, so for them the lock is what keeps the offer honest.)

The offer also records which order used it (order_id), so the admin can see exactly where every discount went.

Step 6: guests become customers without losing anything

A guest browses for a week, builds up history, earns a hesitation offer, and then signs up to check out. If personalisation forgot all of that at sign-in, the offer they were shown would vanish at the worst possible moment.

So signing in runs Interactions::mergeGuestInto() in one transaction. For each of the guest's interaction rows (locked), it either adds the counters into the customer's existing row for that product or simply re-labels the row from g:… to u:42. Then the guest's live offers move across too, and both visitors' cached offers are cleared. There's a test for it: "guest history follows the customer into their account".

Step 7: is any of this working? A/B tests

Personalisation needs to be measured, so the same visitor key powers a minimal A/B system. Experiments live in config (for example the home page's main button: "browse the shop" or "start from a symptom"), and a visitor's variant is:

$variants[crc32($visitor.'|'.$experiment) % count($variants)];

The hash makes the first assignment deterministic, and adding the experiment name means one visitor's buckets in different experiments are independent. The result is then stored in experiment_assignments, because the hash alone has a flaw I describe below. Events (exposure, click, add to cart, purchase) go into experiment_events with insertOrIgnore, so each visitor counts once per event, and the admin dashboard shows unique conversion rates per variant.

The assistant reads the same data

Zovita+ has a small assistant, and it's another consumer of all this. It has no free-text box: the shopper picks a question like "Do I have any discounts?" and the server answers from their live offers, their bag and their orders. Because the answer is assembled from the same OfferEngine::active() the bag uses, the assistant can't promise a discount the checkout won't honour.

What I'd be honest about

Rules only find what I thought of. They're explainable and testable, but they won't discover that people who buy antacids on Fridays also buy rehydration salts. A real store with real traffic could add a learned "pairs well with" without touching the offer rules.
A/B buckets used to change at sign-in. The hash uses the visitor key, and that key changes from g:… to u:… when a guest signs in, so a guest could see variant A and then variant B as a customer, and be counted in both. I fixed it after the first version of this article: assignments are now stored, and signing in carries the guest's variant into the account in the same locked transaction as the interaction merge, unless the account already has one from another device. Nobody switches buckets, and nobody is counted twice.
Clearing cookies resets a guest. That's a privacy feature as much as a limitation, but it means "hesitation" only works within one browser until someone signs in.
Dwell time is self-reported. It's clamped, rate-limited and only ever worth an 8% offer capped at 15% of an order, which is why it's safe to trust a little. I wouldn't let it drive anything more valuable.

What it taught me

Personalisation sounds like a data-science problem, and the rules really were the easy part: six if statements. Almost all of the engineering went into keeping the money honest: one function that prices the bag and the order, a cap in one place, offers locked and redeemed inside the checkout transaction, and history that survives a guest signing in. A store that notices you is nice. A store that notices you and then charges you something different from what it showed you is worse than one that never noticed at all.

The code is on GitHub under the MIT licence. The full build story, including the 3D body map, the admin panel and the bugs, is in the Zovita+ case study.

Find me across the web:

Portfolio: ahmershah.dev
Crunchbase: @syed-ahmer-shah
Crunchbase Company: @syedahmershah
Clutch: @syed-ahmer-shah
Tech Behemoth: @syed-ahmer-shah
Design Rush: @syed-ahmer-shah
Edverise: @syed-ahmer-shah
Trust Pilot: ahmershah.dev
LinkedIn: Syed Ahmer Shah
GitHub: @ahmershahdev
AWS Builder Profile: @syedahmershah
DEV: @syedahmershah
Medium: @syedahmershah
Hashnode: @syedahmershah
Substack: @syedahmershah
HackerNoon: @syedahmershah
Substack: @syedahmershah
Facebook: @ahmershahdev
Linkedin Page: @syedahmershah
YouTube: @ahmershahdev
Instagram: @ahmershahdev
TikTok: @ahmershahdev

Zovita+: Building an Online Pharmacy That Adapts to Each Shopper

Syed Ahmer Shah — Tue, 06 Oct 2026 15:07:49 +0000

Buying medicine online in Pakistan usually means one of two things. Either a big pharmacy chain's site that feels like a spreadsheet, or a WhatsApp number you message with a photo of the box. Neither tells you whether the thing is in stock before you pay, neither knows what you bought last month, and neither has an answer when you don't know the name of the medicine, only where it hurts.

Zovita+ is my attempt at the pharmacy I'd actually want to use. It has 1,186 real medicines, syrups and supplements, a 3D body map you can tap when you don't know what to search for, a store that quietly learns what you need and offers you personal discounts, warnings when two medicines in the bag shouldn't be taken together, refill reminders, pharmacist-reviewed prescriptions, English and Urdu, and card payments or cash on delivery. I designed and built it alone: research, UI, database, backend, admin panel, security, SEO, tests and documentation.

This is how it's put together, what went wrong, and what I'd change.

Two versions of the same idea

Zovita started in March 2026 as a set of flat PHP pages with hand-written Tailwind: a home page, a catalogue, a cart and a prescription upload form. It looked fine in screenshots. Underneath, every page included its own header file, the cart lived in JavaScript, and "checkout" was a form that sent an e-mail. By May I was spending more time fixing the off-canvas menu than building features, and I stopped.

In late September 2026 I rebuilt it from an empty Laravel project. Same name, same brand, nothing else kept. The rebuild is what this case study is about.

The one rule

"Never sell what isn't on the shelf, and never charge a price you didn't show."

A shop can apologise for a late parcel. Telling someone with a fever that the paracetamol they paid for doesn't exist, or charging them more than the bag said, is a different kind of failure. Most of the design decisions below come back to that sentence.

Who uses it

Shoppers browse 8 departments, 118 categories and 212 brands, filter by form, prescription status, stock and price, search with ⌘K, tap the body map when they only know the symptom, ask the assistant where their order is, upload a prescription, and pay by card or cash on delivery. Guests can do all of it; signing in merges the guest wishlist and history into the account.
Pharmacy staff sign in at a separate, unlinked /admin login, as an owner, pharmacist or support, each with its own permissions. They review prescriptions, confirm and dispatch orders, refund card payments, watch stock, read each customer's activity timeline and, when it's needed, ban someone.

Choosing the stack

I wanted an interface that feels like an app, with no full page reloads, and a backend where routing, authentication and validation stay on the server where I can reason about them.

Laravel 12 and React 19, joined by Inertia 2, gave me both. Every page is a React component, but there is no public JSON API to secure. A controller validates the request, checks who is asking and hands props to the page. The store layout never unmounts, so the header, the bag count and the assistant survive navigation.

Layer	Choice	Why
Backend	Laravel 12, PHP 8.2	Routing, Eloquent, queues, scheduler, rate limiting, mail
Bridge	Inertia 2 + Ziggy	SPA navigation with server-side routing and auth
Frontend	React 19, Tailwind CSS 4	Components and one set of design tokens for two themes
Motion and 3D	GSAP (ScrollTrigger, SplitText), Lenis, Three.js via @react-three/fiber	Page motion, smooth scroll, the pill hero and the body map
Database	MySQL / MariaDB	Foreign keys, unique guards, row locks
Maps	Leaflet, OpenStreetMap, Nominatim	The address picker and the contact map, with no API key
Payments	Stripe Checkout (a sandbox gateway locally)	Card payments confirmed only by signed webhooks; cash on delivery always works
Mail and bots	Resend, reCAPTCHA v3 + v2	Transactional e-mail; invisible bot scoring with a checkbox fallback
Rendering and scale	Inertia SSR, Redis, ClamAV	Full HTML for crawlers, shared rate limits and bans across servers, scanned uploads

Architecture

The rule I kept coming back to was thin controllers, and one class for every set of rules that must hold together. Placing an order has to lock stock, check prescriptions, store the prescription file, apply personal offers, create the order, mark offers as redeemed, and only after that commits, clear the bag, record the purchase and send e-mail. All of that lives in one PlaceOrder action, so there is exactly one place where an order can come into existence.

Other decisions that paid off:

One source of truth per concern. App\Support\Seo builds titles, Open Graph and JSON-LD for every page. The FAQ and policies live in resources/content/*.json and feed the pages, their JSON-LD and llms-full.txt from the same file.
Personalisation is a set of small services, not a model: Visitor (who is this, signed in or not), Interactions (what did they do), OfferEngine (what does that earn them), Pricing (what does it cost now) and Recommender (what should they see next).
The scheduler does the boring, important work. Every ten minutes it accepts prescriptions nobody has reviewed in 24 hours, so a customer is never stuck because the pharmacist was busy; every five it cancels and restocks card orders nobody paid for; every morning it sends refill reminders.

The data model

The schema is 22 domain tables and 27 foreign keys. The catalogue is simple: a department has categories, and a product belongs to a department, a category and (optionally) a brand. A product carries real pharmacy data: price and sale price, stock, a per-order cap, whether it needs a prescription, its active ingredients (generics), uses, dosage, precautions and warnings.

An order has order items that copy the product's name, price and image at the moment of sale, so editing a product later never rewrites someone's receipt. An order can point to a prescription, which points to the staff member who reviewed it.

What makes it trustworthy is what the database itself refuses:

orders.number is unique, and so is orders.checkout_token: a double-tapped "Place order" can only ever create one row.
prescriptions.reference, products.slug, users.username and users.email are unique.
Foreign keys decide what happens on delete: removing a product cascades its wishlist entries and interaction history but only nulls order_items.product_id, because the order has to survive.

Money has its own tables: a payment per checkout attempt and a refund per refund, with webhook_events storing every gateway event id once so a replayed webhook is a no-op.

The other half of the schema is about people: product_interactions (one row per visitor and product), offers, refill_reminders, experiment_events and experiment_assignments, login_codes, bans, ban_identifiers and user_activities. I'll come back to those.

Ordering

The bag is a session, and every price in it is re-read from the database on each request. Nothing the browser says about price is ever trusted. Checkout, whether cash on delivery or card, is a single transaction:

Lock. The products in the bag are read with SELECT … FOR UPDATE, in ascending id order. Two checkouts that share products queue behind each other instead of deadlocking, because they always take locks in the same order.
Re-check and decrement. Stock is checked under the lock and then decremented with UPDATE … WHERE stock >= qty. If that affects no row, the whole transaction rolls back. Stock can't go negative even if a future change forgets the lock.
Prescriptions. If any item needs one and no file is attached, the order stops there. The file is stored on a private disk; if the transaction rolls back, the file is deleted again.
Offers. The visitor's live offers are locked too, so one offer can't be redeemed by two parallel checkouts, and the discount is computed by Pricing::apply(), the same function that priced the bag preview.
Create. The order gets a random number under a unique index (a collision just retries inside a savepoint) and the checkout token under another one. Deadlocks retry up to three times.

Only after the commit does the bag clear, the purchase get recorded and the e-mails go out. The loser of a "one unit left, two buyers" race sees a normal message asking them to review the bag, not an error page.

When something is sold out, the product page offers in-stock alternatives with the same active ingredient first, then the same category at a similar price, with a one-tap swap in the bag.

Paying by card

Card payments go through Stripe Checkout in production and a built-in sandbox gateway locally, so the whole flow can be tested without keys. The order is created awaiting payment with its stock reserved for 30 minutes. The page the customer returns to never marks anything paid: only a webhook does, and only if its HMAC-SHA256 signature checks out in constant time, its timestamp is under five minutes old, its event id has never been seen, and the amount and currency match the order. If nobody pays, payments:expire cancels the order, puts the stock back and releases its offers; money that arrives after that is refunded automatically. Owners refund part or all of an order from the admin panel, and refunds can never exceed what was captured.

Medicine safety

Every product stores its active ingredients, so the bag can do what a careful pharmacist would: notice two medicines that shouldn't be taken together. An InteractionChecker maps ingredients to drug classes (NSAIDs, blood thinners, SSRIs, nitrates, macrolides…) with tolerant patterns, so the catalogue's own spellings still match, and checks them against 24 conservative, well-established rules: two paracetamol products, a blood thinner with an anti-inflammatory painkiller, sildenafil with a nitrate, and so on. Creams, shampoos and drops are ignored, so a ketoconazole shampoo never warns about a statin. Each warning says what to do; a serious one must be acknowledged before the order goes through, and the pharmacist sees it on the order. It's an automatic check, not medical advice, and the page says so.

The same purchase history drives refill reminders. For a medicine someone buys again and again, the median gap between their real orders (7 to 120 days) gives the rhythm, and an e-mail goes out three days before they should run out, once per purchase cycle, with a signed one-tap link that puts it back in the bag.

The 3D body map

Plenty of people know where it hurts but not what to search for. The body map is for them: rotate a mannequin, tap where it hurts, pick a symptom, and get self-care tips, red flags and pharmacist picks from the catalogue. Emergency symptoms (chest pain, trouble breathing) show urgent-care guidance instead of products.

I didn't want to ship a stock 3D model I couldn't control, so the figure is sculpted in code. A Node script defines the body as a signed distance field (ellipsoids and tapered capsules blended with a smooth minimum so joints flow without seams), meshes it with surface nets, and bakes a binary file where every vertex carries its body region id. The shader uses that id for the region glow and the picking. The result is 775 KB raw and 463 KB with Brotli, and it only loads on the body map page.

A store that notices

Every visitor, signed in or not, builds a quiet profile: how many times they viewed each product, how long they stayed, what they added to the bag and what they bought. From that, an offer engine creates personal discounts: 8% on something you keep coming back to, 5% on something left in the bag, 10% on something you buy every month, a welcome or loyalty discount on the whole order. Every offer is time-limited, the total is capped at 15%, and it's locked and redeemed inside the checkout transaction.

It also powers "picked for you", "buy again" and "pairs well with" rails, and a guided assistant. The assistant has no free-text box: you pick from preset questions ("Where is my order?", "Do I have any discounts?", "What's in my bag?") and the answer is built on the server from your data. Nothing a visitor types is sent anywhere, so there is nothing to prompt-inject and no made-up medical advice.

I wrote a separate article about how the offers work and the bugs I found in them: The discount that knew you were hesitating.

The admin panel

The admin panel is for pharmacy staff, not developers, so I wrote it around one question: "what does this person need to do right now?"

It hides. It has its own sign-in at /admin/login, every admin URL answers 404 to anyone who isn't staff, sessions end after 30 minutes idle, and staff login locks for 15 minutes after five failures. Each staff member can turn on two-step sign-in with an authenticator app from My security; from then on every sign-in needs its code, a used code can't be replayed, and hashed single-use recovery codes cover a lost phone.
Roles decide what you see. Owners can do everything, including refunds, bans and managing staff; pharmacists handle prescriptions, stock and prices; support sees orders and customers but can't refund or ban. Permissions are checked on every route and the sidebar only shows what a role can open. The last owner can never be demoted.
"Today at Zovita" opens with to-do cards (prescriptions to review, orders to confirm, low and sold-out stock), then revenue, orders, average order and new customers against the previous period, and charts for revenue per day, the shopper funnel, top products, departments and A/B results. Every chart has a table view.
It explains itself. Every page has a "How this page works" guide, every heading has a ? with a plain-language explanation, and statuses are big coloured pills, not codes.

Prescriptions can be accepted, rejected or left pending with a note that is e-mailed to the customer. Anything not reviewed within 24 hours is accepted automatically and labelled "auto-approved", so it's obvious which ones a person actually looked at.

Customers have a full activity timeline (sign-ins, views, bag, orders, prescriptions, profile changes, with device and IP) and a ban wizard with three levels: temporary (until a date), permanent (the email, phone and device can't register again) and deep (also the IP, its /24 or /64 network and the browser fingerprint, across the whole site). E-mail matching is canonical, so Gmail dots and +aliases are folded and j.o.h.n+1@gmail.com is the same person as john@gmail.com.

Design and language

The brief I set myself was "calm": deep navy ink, a soft mint accent, warm paper, and generous space, because people buying medicine are often unwell or worried. Motion is there to explain, not to impress: an item you add to the bag flies into it as a little parcel with a trail, moving it to "saved for later" flies it back, and un-saving from the wishlist plays a small heart-break. All of it switches off under prefers-reduced-motion.

Urdu is a first-class language, not a translation layer bolted on. Switching is instant with no reload, the whole layout flips right-to-left, and the type changes to Noto Nastaliq Urdu. The dictionary has about 1,460 entries and covers the storefront, policies, FAQ, checkout, the admin panel and the error pages; values that change (counts, prices, names) go through placeholders, and dates use Urdu month names. Product names, prices and order numbers stay in Latin script so they match the box and the receipt.

Even the 404 is useful: it has search and shortcuts instead of a dead end.

SEO, and search for AI

Every storefront page is server-rendered (Inertia SSR) and hydrates without a mismatch, and the server does the rest of the work for crawlers:

Server-rendered head. Every page gets a unique title and description, a canonical URL, Open Graph and Twitter cards, a robots rule, and hreflang alternates for English and Urdu.
JSON-LD. Pharmacy and OnlineStore site-wide, WebSite with a search action, and per page Product (offers, availability, brand), BreadcrumbList, FAQPage, ItemList and ContactPage.
A generated sitemap with every product, department, category, brand and page, and llms.txt / llms-full.txt for AI assistants. robots.txt lets named AI crawlers in and keeps everyone out of the bag, checkout, account and admin.

Lighthouse 13 scores 100 for accessibility, best practices and SEO on the home, shop, product, body map, FAQ, contact, policy, login, register, prescription and about pages. The bag and checkout are noindex on purpose and lose SEO points for it.

Security

Area	What protects it
SQL injection	Eloquent and the query builder with bound parameters everywhere; sort and filter values are allow-listed. Tests send classic payloads.
XSS	React escaping plus a nonce-based Content-Security-Policy, so no inline script runs without the per-request nonce
CSRF and clickjacking	CSRF tokens on every state change, `SameSite=Lax` cookies, `frame-ancestors 'self'`, HSTS in production
Brute force	Per-route throttles, each with its own counter; 5 failed sign-ins lock for a minute (15 on the staff login); reCAPTCHA v3 with the v2 checkbox as a fallback
Floods	A `RequestGuard` middleware rejects unexpected methods, huge URLs, parameter floods, oversized bodies and NUL bytes before any session or database work; a per-client budget; nginx `limit_req` at the edge
Races	Row-locked stock and offers, conditional decrements, idempotency tokens
Enumeration	Password reset, login and order tracking answer the same way whether or not the account or order exists
Uploads	MIME and extension allow-list, size cap, UUID names, a private disk, streamed only to staff
Admin	404 for non-staff, a separate login, optional authenticator-app two-step sign-in, role permissions on every route, idle timeout, every admin action in the activity log
Payments	Server-computed amounts; webhooks verified by HMAC with a 5-minute window, each event applied once, amount and currency must match; refunds capped at what was captured
Malicious files	Prescriptions and avatars are streamed to ClamAV before they're stored; if the scanner is down, the upload is refused

Testing

Suite	What it covers	Result
PHPUnit	Checkout (stock locking, idempotency, throttle isolation), auth, TOTP against the RFC 6238 vectors, roles, bans and evasion, offers, assistant, A/B, admin gating, prescriptions and the 24 h auto-accept, payments (forged, stale, duplicate and wrong-amount webhooks, expiry, late-payment refunds), interactions, refills, ClamAV, SQLi/XSS/CSP/CSRF, SEO outputs	145 passed, 973 assertions
Playwright	Every page on desktop and a phone (no console errors, one `h1`, no sideways scroll), fly-to-bag, wishlist and bag moves, guest checkout, keyboard use of the themed dropdowns, body map, assistant, Urdu round-trip, A/B exposure, prefetch, admin review, admin pages on a phone, interaction warnings, a card payment through the sandbox gateway	56 passed
Load	autocannon on a single XAMPP dev box: shop and product pages about 32 requests a second, FAQ about 55, static images about 830	No errors
Abuse	25 connections flooding the shop from one client for 20 s	293 served, then 429 for the rest, no 5xx

CI runs Pint, the production build and the PHPUnit suite on every push. The repository has a single branch, main, protected by rulesets: no force-pushes or deletion, linear history, signed commits only, and no other branch can be created.

Where it broke

This is the part I'd want to read in someone else's case study.

Shopping used up the checkout limit. Every write route had a throttle, and I was proud of that. But Laravel's throttle:60,1 keys the counter by user or IP, not by route, so all of them shared one bucket. A shopper who added and removed a few things from the bag, toggled the wishlist and changed the language could hit "Too many requests" on Place order, the one request that matters. Every throttle now names its own counter (throttle:6,1,checkout.store), and a test proves bag activity can't exhaust checkout.

The mobile menu closed itself. Hovering a link prefetches its page, so clicks feel instant. The mobile menu and the overlays closed themselves on Inertia's start event, so they could close themselves the moment a prefetch began, which is the opposite of what anyone wants from a menu they just opened. Overlays now ignore visits that are prefetches.

The header pushed its own menu button off-screen. Between 320 and 375 px, and again at 1024 px, the header was wider than the screen and the menu button sat past the right edge, so on the smallest phones you couldn't open the menu at all. The smoke test that checks "no sideways scroll" now runs on a phone profile for every page.

Nastaliq got its tops cut off. Nastaliq is a tall, joined script: the strokes of letters like کاف and گاف rise well above the line box. The text reveals mask each line with overflow: hidden, and the rolling button labels clip to one line height, so both sliced the tops off Urdu letters. Under html[lang='ur'], line masks and labels now leave room for the strokes.

The admin dashboard scrolled sideways on phones. I found this one while writing this case study. The dashboard's chart grid had no column template below the xl breakpoint, so its single implicit column grew to fit the widest chart and the page became 698 px wide on a 375 px phone. The customers list had the same problem. Adding grid-cols-1 (which is minmax(0, 1fr)) fixed both. The same bug bit me on BookMyMovie, and the lesson is the same: a check that runs every page at 320, 375, 414, 768, 1024, 1280 and 1920 px catches what my eyes don't. It now covers the admin pages too.

A section that was invisible everywhere. The "Shop by concern" grid never appeared, on any screen. Its cards fade in on scroll with gsap.from(), which animates from a value to whatever the element's opacity is when the tween is set up. The cards also had a CSS transition on opacity, so when ScrollTrigger refreshed after the web fonts loaded, GSAP re-read the opacity in the middle of that CSS transition, got roughly zero, and animated from zero to zero. Giving the tween explicit end values with fromTo() fixed it. The lesson: never let CSS transitions and GSAP fight over the same property.

A hundred and fifty products called "None". The catalogue source writes None when a product has no listed ingredient. Stored as-is, it showed up as an ingredient chip on product cards, and worse, "same salt, other brand" treated all 150 of those products as substitutes for each other. A migration now stores it as unknown, and the importer refuses the placeholder.

English text, flipped right to left. The Urdu layer lived in the store layout, but the admin panel, the admin login and the error pages each have their own layout. In Urdu they rendered English text with dir="rtl", which is worse than either language. Monospace labels had a subtler problem: the mono font has no Urdu glyphs, and the browser's fallback drew the letters unjoined. Every layout now mounts the language layer, and every font stack falls back to Nastaliq.

CI that couldn't start. CI copies .env.example, where a few optional settings are blank. env('CACHE_LIMITER_STORE') returns an empty string, not null, so Laravel looked for a cache store named "" and crashed before the first test ran. Empty now means "not set".

Downsides I'd be honest about in a review

Cards, but no local wallets. Stripe covers cards; most Pakistani shoppers would also expect JazzCash and Easypaisa.
Two-step sign-in is opt-in for staff. The demo accounts need to work with a password, so the panel nudges each staff member to turn it on rather than forcing it. A real pharmacy should make it mandatory.
Auto-accepting prescriptions is a product decision, not a medical one. It keeps customers from waiting on a busy pharmacist, and it's clearly labelled, but a real pharmacy would need a regulator's view on it.
The catalogue is borrowed. Names, prices and images come from a public pharmacy storefront for demonstration only. A real launch needs a licensed catalogue and live stock from the pharmacy's own system.
Personalisation is rules, not learning. The rules are explainable and testable, which I wanted, but they won't find patterns I didn't think of.
Interaction checks are deliberately narrow. Twenty-four well-established rules catch the common, dangerous pairs; they are not a clinical decision-support system and don't know the patient's other medicines.

Where it stands

Zovita+ is finished as a portfolio project. The code is on GitHub with a step-by-step setup guide; it runs locally with no third-party keys at all, and one migrate --seed loads the catalogue and the demo accounts.

The first version of this case study ended with a list of what I'd build next. All of it has since shipped: staff roles with two-step sign-in, card payments with signed webhooks and refunds, refill reminders, drug-interaction warnings, server-side rendering, Redis-ready rate limits and bans, and malware scanning on uploads, along with e-mail automation and a full Urdu pass over every page. If I picked it up for a real pharmacy, the next list would be:

JazzCash and Easypaisa next to cards, and mandatory two-step sign-in for staff.
Passkeys, and SMS or WhatsApp updates for orders and refills.
A pharmacist chat handoff from the assistant.
Back-in-stock alerts and verified-purchase reviews.

What it taught me

The interesting work in a pharmacy isn't the product grid. It's the rate limit that quietly blocks checkout, the offer that two tabs try to redeem at once, the menu that closes because a link was hovered, and the Urdu letter that loses its top to an animation mask. Almost everything I'm proud of in Zovita+ is invisible when it works.

The code is on GitHub under the MIT licence, with the full data model, security design, test results and every screen in the README.

Find me across the web:

Portfolio: ahmershah.dev
Crunchbase: @syed-ahmer-shah
Crunchbase Company: @syedahmershah
Clutch: @syed-ahmer-shah
Tech Behemoth: @syed-ahmer-shah
Design Rush: @syed-ahmer-shah
Edverise: @syed-ahmer-shah
Trust Pilot: @ahmershah.dev
LinkedIn: Syed Ahmer Shah
GitHub: @ahmershahdev
AWS Builder Profile: @syedahmershah
DEV: @syedahmershah
Medium: @syedahmershah
Hashnode: @syedahmershah
Substack: @syedahmershah
HackerNoon: @syedahmershah
Substack: @syedahmershah
Facebook: @ahmershahdev
Linkedin Page: @syedahmershah
YouTube: @ahmershahdev
Instagram: @ahmershahdev
TikTok: @ahmershahdev

The Last Mango Problem: Race Conditions in a Real Marketplace

Syed Ahmer Shah — Thu, 01 Oct 2026 19:38:11 +0000

There's one Sindhri mango left at the Latifabad stall. Two people tap "Place order" at the same moment. Who gets it?

If your answer is "whoever was first", you've already made the mistake this post is about. Computers don't do "first" the way people do. Two requests can land in the same millisecond, both read the stock, both see 1, both subtract one, and both leave happy. The farmer now owes somebody a mango that doesn't exist.

I ran into this properly while building GleanGrid, a pre-order marketplace for Hyderabad's farmers markets that I built on my own. This is how it handles the moments where people collide: the last item, the single-use coupon, the nearly full pickup window, the double-tapped button, the payment that arrives late. It also covers a MySQL detail that fooled code which looked perfectly correct to me.

Why "check, then write" is broken

Here's the naive version. I'd bet most first checkouts look like it; mine did.

$product = Product::find($id);

if ($product->stock_quantity >= $qty) {
    $product->stock_quantity -= $qty;
    $product->save();
}

Run that from two requests at once and both pass the if before either one saves. The gap between the read and the write is tiny, but a busy Saturday morning is exactly when a lot of people land in it together.

Rule one: lock the thing you're about to change

The fix is to make the read and the write one indivisible step. In MySQL that means a transaction plus a locking read, SELECT … FOR UPDATE. The first request to get the lock holds it until it commits. Everyone else waits in line and then sees the updated number.

$products = Product::whereIn('id', $ids)
    ->where('farmer_profile_id', $farmer->id)
    ->orderBy('id')
    ->lockForUpdate()
    ->get();

Two details matter here.

Lock in a fixed order. A basket can hold several products. If one checkout locks the mangoes and then the honey while another locks the honey and then the mangoes, each ends up waiting for the other forever. That's a deadlock. Sorting by id means everyone queues in the same order, so the cycle can't form.

Merge duplicate lines first. If a basket somehow holds the same product twice, checking each line against the stock separately lets 2 + 2 sneak past a stock of 3. GleanGrid sums the lines per product before it checks anything.

Rule two: the same goes for coupons

A coupon with a usage limit of one is just another counter that fifty people want to decrement. Same medicine: lock the coupon row, check it, record the redemption and bump the counter, all inside the checkout transaction.

$coupon = Coupon::where('code', $code)->lockForUpdate()->first();
$this->assertUsable($coupon, $order->farmer_profile_id, $subtotal, $user);

CouponRedemption::create([...]);
$coupon->increment('used_count');

Because I don't fully trust myself, the database gets the last word too:

ALTER TABLE coupons ADD CONSTRAINT chk_coupon_usage
  CHECK (usage_limit IS NULL OR used_count <= usage_limit);

If a future change ever forgets the lock, MySQL refuses the write instead of quietly giving away a discount.

Rule three: the pickup window, and the bug I didn't see

Each farmer offers pickup windows with a capacity, say three orders between 7 and 8 am, so the stall doesn't get swamped. This code looked right to me:

$slot = $farmer->pickupSlots()->lockForUpdate()->find($slotId);

$booked = Order::where('pickup_slot_id', $slot->id)
    ->whereDate('pickup_date', $date)
    ->whereIn('status', Order::OPEN)
    ->count();

if ($booked >= $slot->capacity) {
    throw ValidationException::withMessages(['pickup' => 'That pickup window is fully booked.']);
}

Lock the slot, count the bookings, reject if it's full. The unit test passed. Then I wrote a stress script that fires real, separate PHP processes at checkout at the same instant, and it said this:

Twenty orders in a window built for three. The lock was there. So what went wrong?

Snapshots under REPEATABLE READ

MySQL's InnoDB engine runs at the REPEATABLE READ isolation level by default. Inside a transaction, a normal SELECT doesn't read the latest data. It reads a snapshot, and that snapshot is fixed at the transaction's first ordinary read.

My checkout's first read was loading the farmer's profile, before it asked for the slot lock. So each request:

read the farmer, which fixed its snapshot at that moment;
waited in line for the slot lock while other checkouts committed their orders;
got the lock and ran count() against its old snapshot, which contained none of those new orders.

The lock serialised the requests perfectly. It just didn't change what they could see. Stock and coupons were never affected, because I read those rows with FOR UPDATE, and locking reads always see the latest committed data, not the snapshot.

I'll admit I stared at this one for a while. What finally cracked it was writing down, step by step, what each transaction could see at each moment. I talked it through with Claude as well, and it asked the question that mattered: when does this transaction take its snapshot? The answer was in my own code, three lines above the lock.

The one-line fix

Make the count a locking read too:

$booked = Order::where('pickup_slot_id', $slot->id)
    ->whereDate('pickup_date', $date)
    ->whereIn('status', Order::OPEN)
    ->lockForUpdate()
    ->count();

Then I ran it again, this time with fifty buyers:

The lesson I'm keeping: inside a transaction, a lock decides who goes next. It doesn't decide what they see. Anything you use to make a decision under a lock should itself be read with a lock.

Rule four: the double-tap

The most common race isn't fifty strangers. It's one person on a slow connection pressing "Place order" twice, or checking out in two tabs. GleanGrid wraps the whole checkout in a short, per-customer atomic lock:

$lock = Cache::lock("checkout:{$customer->id}", 15);

if (! $lock->get()) {
    throw ValidationException::withMessages([
        'checkout' => 'Your previous checkout is still being processed. Please wait a moment.',
    ]);
}

In the stress test, ten simultaneous submissions from one account produce exactly one order and nine polite messages. While writing this I also noticed that the "too many open orders" check ran before that lock was taken, which left a small window for going one over the limit. It now runs inside.

Rule five: the races that don't look like races

Once you start looking, they're everywhere. These three never showed up in a stress test, because they need a person and a clock rather than fifty processes.

The farmer's stale form. A farmer opens the stock form at 7:00, when there are 20 bunches of spinach. Customers buy five while the form sits open. At 7:10 the farmer saves the form, still showing 20, and quietly erases five sales. That's a lost update. Now the form sends back the number it showed along with the new one, and the server works out what happened in between:

private function reconcileStock(Product $locked, int $submitted, ?int $seen): int
{
    if ($seen === null) {
        return $submitted;
    }
    if ($submitted === $seen) {
        return $locked->stock_quantity; // field untouched: keep what's really there
    }

    // subtract whatever sold since the form was opened
    return max(0, $submitted - max(0, $seen - $locked->stock_quantity));
}

The Monday restock. "Apply weekly template" used to read every product, then write its usual quantity back. A reservation made between the read and the write was overwritten. It's now one atomic statement per run, with no read-modify-write loop to fall into:

UPDATE products SET stock_quantity = weekly_quantity WHERE ...;

Two restocks, two e-mails. When a sold-out item comes back, everyone who asked gets one alert. If two restocks fire at once, both could see the same pending alerts. Each alert is now claimed with a conditional update, and only the process that wins the row sends the message:

StockAlert::whereKey($alert->id)
    ->whereNull('notified_at')
    ->update(['notified_at' => now()]) === 1; // only one process ever gets a 1

The same trick, "update where it's still in the state I expect, then check how many rows changed", turns up all over GleanGrid. It's the cheapest correct lock there is.

Rule six: money is where races get expensive

Online payments came later, and I treated them as the riskiest code in the project. A double charge isn't an awkward message at a stall; it's someone's money.

One attempt at a time. The payment row is locked and moves from pending to processing exactly once. A second tap while the first is in flight gets "payment in progress", not a second charge.
Replays are harmless. Every attempt carries a one-time idempotency key, stored under a unique index. If a flaky connection makes the browser resend the same request, the server recognises the key and returns the existing result.

$locked = Payment::whereKey($payment->id)->lockForUpdate()->firstOrFail();

if (PaymentEvent::where('payment_id', $locked->id)->where('idempotency_key', $key)->exists()) {
    return false; // already handled: answer with what happened, charge nothing
}
if ($locked->status === 'processing') {
    throw ValidationException::withMessages(['payment' => 'payment.in_progress']);
}

Late confirmations are refunded, not lost. If the gateway confirms after the 20-minute window has closed, the stock may already be back on sale. GleanGrid notices the payment is no longer processing, records a late_capture event and refunds automatically.
Refunds can't run twice either: they go through a conditional UPDATE … WHERE payment_status = 'paid'.

Rule seven: let the loser see a form error, not a crash

Some races end at a unique index rather than a lock. Two people pick the same username at the same moment, and both pass the "is this taken?" check because neither has saved yet. The database lets one through and rejects the other with a duplicate-key error, which by default becomes a server error page.

GleanGrid maps that one exception, everywhere, to an ordinary validation message:

$exceptions->map(UniqueConstraintViolationException::class, function ($e) {
    $field = collect(['email', 'username', 'code', 'slug'])
        ->first(fn ($f) => str_contains($e->getMessage(), $f)) ?? 'form';

    return ValidationException::withMessages([
        $field => __('validation.unique', ['attribute' => $field]),
    ]);
});

The second person sees "The username has already been taken" under the field, exactly as if they'd been a second slower.

What about thousands of people at once?

Correctness under concurrency and survival under load are different problems, so they get different tools.

Updates that don't compete are cheap. A thousand people editing their own profiles touch a thousand different rows. InnoDB locks rows, not tables, so those writes never wait on each other.

Hot rows are the real bottleneck. A thousand people buying the same product queue on that one row. Each transaction is short (lock, check, write, commit, a few milliseconds), and the rare deadlock is retried automatically:

DB::transaction(fn () => /* place the order */, attempts: 3);

Floods get turned away early. Every page sits behind a site-wide rate limiter, 300 requests a minute per IP for guests and 600 per signed-in account, with much tighter limits on sign-in, sign-up, password resets, search, checkout and payments. Writes are capped at sixty a minute per account, while page views stay unrestricted so browsing never feels throttled.

RateLimiter::for('global', fn (Request $request) => $request->user()
    ? Limit::perMinute(600)->by('u:'.$request->user()->id)
    : Limit::perMinute(300)->by('ip:'.$request->ip()));

Bots don't get to race at all. Every public form carries a signed ticket issued with the page, so a script can't hammer the sign-up form without first loading it, waiting, and passing a Turnstile or reCAPTCHA check.

Real denial-of-service protection belongs in front of the app. No PHP code can absorb a flood that saturates the network. In production GleanGrid is meant to sit behind Cloudflare, which soaks up volumetric attacks before they reach the server. Because the app only trusts X-Forwarded-For from proxies listed in TRUSTED_PROXIES, rate limits apply to the real visitor rather than the proxy, and nobody can dodge them by faking the header.

Test it the way it breaks

The most useful thing I built for all this wasn't a lock. It was the script that fires fifty real processes at the same instant against the real database, checks the numbers afterwards and cleans up after itself. Unit tests run in one process, one request at a time, so they'll happily pass code that falls over the moment two requests overlap.

If your application sells anything that can run out, write the test that makes things overlap on purpose. Then ask the question that caught my bug: at this line, what can this transaction actually see?

The whole project, stress script included, is on GitHub. If you've been bitten by a race condition of your own, I'd love to hear the story.

Originally published at https://ahmershah.dev/blogs/the-last-mango-problem-race-conditions-in-a-real-marketplace — © Syed Ahmer Shah

Find me across the web:

Portfolio: ahmershah.dev
Crunchbase: @syed-ahmer-shah
Crunchbase Company: @syedahmershah
Clutch: @syed-ahmer-shah
Tech Behemoth: @syed-ahmer-shah
Design Rush: @syed-ahmer-shah
Edverise: @syed-ahmer-shah
Trust Pilot: @ahmershah.dev
LinkedIn: Syed Ahmer Shah
GitHub: @ahmershahdev
AWS Builder Profile: @syedahmershah
DEV: @syedahmershah
Medium: @syedahmershah
Hashnode: @syedahmershah
Substack: @syedahmershah
HackerNoon: @syedahmershah
Substack: @syedahmershah
Facebook: @ahmershahdev
Linkedin Page: @syedahmershah
YouTube: @ahmershahdev
Instagram: @ahmershahdev
TikTok: @ahmershahdev

GleanGrid: Building a Pre-Order Marketplace for Farmers Markets

Syed Ahmer Shah — Tue, 29 Sep 2026 14:13:50 +0000

Every week, growers from Tando Jam, Kotri, Thatta and Mirpurkhas bring vegetables, mangoes, dairy, honey and bread into Hyderabad. The markets themselves are great. Everything around them is guesswork. You rarely know which farmer will turn up, what they'll bring or what it'll cost, and the Sindhri mangoes you crossed the city for are often gone by nine. Farmers have the opposite problem: they can't take an order before market day, so they either pick too much and throw some away, or pick too little and lose the sale.

GleanGrid is my answer to that. I built it for Aptech's TechWiz 7 competition, against a brief called MarketLink: eGreen Basket, and I built all of it myself: the research, the UI, the database, the backend, payments, security, testing and the documentation. Farmers publish their weekly stock, prices and pickup windows. Customers find a market on a map, reserve produce against real stock, pay online or in cash at the stall, and collect it on market day. There's no delivery, on purpose. The market stays the market; the guesswork goes.

This is how it's put together, what I got wrong along the way, and what I'd change next.

The brief, in one sentence

"Let people reserve this week's harvest from a specific farmer, at a specific market, for a specific pickup window, and never promise something the farmer doesn't have."

That last clause shaped almost everything. A shop can apologise for a late parcel. A farmer who drove in at six in the morning with forty kilos of tomatoes cannot sell forty-one.

Who uses it

Three roles, each with a workspace of its own:

Customers browse markets, stalls and produce, fill a basket without an account, then check out with a pickup window per stall. They can change or cancel until the farmer's cut-off, carry a QR pickup pass, save favourites, ask to be told when something sold out comes back, share a family account, and review a farmer after pickup, with photos if they like.
Farmers register a stall (an admin approves it), list weekly stock with photos, set pickup windows with a capacity and a cut-off, and move orders through accepted, ready and completed. At the stall they scan the customer's QR code.
Admins approve or suspend stalls, manage markets and categories, moderate listings, reviews and review photos, tune the stall-badge rules, edit the seasonal calendar, refund payments, answer the contact inbox and read reports across every market.

Choosing the stack

I wanted two things that usually pull against each other: an interface that feels like a modern app, and a backend where routing, auth and validation stay on the server, where I can reason about them.

Laravel 12 and React 19, joined by Inertia.js, gave me both. Every page is a React component, but there's no public API to secure. A controller validates the request, checks who's asking, and hands props to the page. Navigation feels instant because links prefetch on hover and the layout never unmounts; only the page in the middle swaps. Inertia's server-side rendering means crawlers and slow phones get real HTML before any JavaScript runs.

Layer	Choice	Why
Backend	Laravel 12, PHP 8.2	Routing, Eloquent, queues, notifications, rate limiting
Bridge	Inertia.js 3 with SSR	SPA feel, server-side routing and auth, real HTML first
Frontend	React 19, Tailwind CSS 4, Vite	Components, design tokens, fast builds
Motion	Motion, Lenis	Spring physics, layout animation, smooth scroll
Maps	Leaflet + OpenStreetMap, OSRM	Free, keyless maps and routes
Database	MySQL 8 / MariaDB	Foreign keys, CHECK constraints, views, triggers
Mail	Resend	Branded e-mail, sent only after the database commits

Architecture

The rule I kept returning to was thin controllers, services for anything with rules in it. Placing, changing and cancelling an order, moving it between states, redeeming a coupon, taking a payment, awarding a badge, checking a one-time code: all of that lives in OrderService, PaymentService, CouponService, BadgeService and AccountSecurity. They can be tested without HTTP and reused from the customer area, the farmer panel, the admin panel and the scheduler.

A few decisions paid for themselves many times over:

One source of truth per concern. SEO copy lives in one PHP class, rendered on the server and reused by React. Policy and FAQ text lives in one place and feeds the pages, the FAQ structured data and llms.txt.
Notifications are queued and sent after commit. If an order rolls back, nobody gets an "order placed" e-mail for something that never happened.
The web tier is stateless. Sessions, cache and queue sit behind drivers, so moving them to Redis and adding servers is configuration, not a rewrite.
The scheduler does the boring, important work: expiring unpaid checkouts, evening-before pickup reminders, the Monday restock, and the nightly badge recalculation.

The data model

The core schema is 26 tables and four reporting views, with a handful more added later for payments, price history, badges and the seasonal calendar. The shape is simple once you see it: a farmer profile belongs to a user and trades at several markets. It lists products and offers pickup slots at each market. An order belongs to one customer, one farmer, one market and one pickup slot, and holds order items.

What makes it trustworthy is what the database refuses to accept:

Every relationship is a real foreign key with a deliberate ON DELETE rule.
22 CHECK constraints reject impossible data even if a bug slips past PHP: ratings outside 1–5, negative prices, a closing time before an opening time, a coupon used more often than its limit.
order_items keeps a snapshot of the product name, unit and price, so last month's order still says what it said when a farmer edits the listing.
Triggers write every status change into order_status_history, and views like v_market_revenue pre-join the heavy report queries.
Every price change lands in product_price_history, one row per product per day, which is what the price charts read.

One order, many states

An order is a small state machine, and the server is the only place that decides whether a move is legal. A farmer can't mark a cancelled order as ready. A customer can't cancel after the cut-off. Every transition re-reads the order under a row lock first, so a customer cancelling at the exact moment the farmer taps "accept" can't leave it half one thing and half the other. The allowed transitions are unit-tested on their own, separately from the HTTP flows.

Never selling what isn't there

This is the part I'm proudest of, and it has its own article: The last mango problem. The short version: stock, coupons and pickup-window capacity are all decided inside one transaction, under row locks, taken in a fixed order so two checkouts can't deadlock each other.

Unit tests can't really prove that, because they run in a single process. So I wrote a script that launches fifty separate PHP processes at checkout at the same instant, against the real MySQL database.

The first run failed. A pickup window with room for three accepted twenty orders. The cause was a MySQL isolation detail I explain properly in the other article, and the fix was one line. I'd much rather find that with a script than with a queue of annoyed customers at a stall.

The same thinking later caught two quieter bugs. A farmer saving the stock form while customers were buying could overwrite their purchases with the number the form had loaded minutes earlier. And the Monday restock read each product, then wrote it back, which could wipe a reservation made in between. Both are fixed; the article has the details.

Payments, added later, done carefully

The brief said "pay at pickup, no gateway", and cash at the stall is still always there. But a lot of people in Pakistan would rather tap Easypaisa or JazzCash than carry cash, so I added online payment on top of the brief, and I treated it as the riskiest feature in the project.

Placing an online order reserves the stock and opens a payment window (20 minutes by default). Farmers aren't notified and can't accept until it's paid. Unpaid checkouts are released by a scheduled job, which puts the stock back and returns the coupon.
The amount is always recomputed on the server from the orders. The browser never tells the server how much to charge.
A double tap can't charge twice. The payment row is locked, it moves from pending to processing exactly once, and every attempt carries a one-time idempotency key under a unique index, so a replayed request returns the existing result.
Late confirmations are refunded automatically. If the gateway confirms after the window has closed and the stock has gone back on sale, GleanGrid records a late_capture event and refunds.
Card numbers and CVCs are never stored, logged or flashed back to the session. Only the brand and the last four digits are kept.
JazzCash's hosted checkout is wired in with its pp_SecureHash HMAC, checked again on the signed callback in constant time. In sandbox mode a built-in simulator runs the whole flow with test cards, so the competition judges could try it without real money.

Signing in, and not getting taken over

Google and Facebook sign-in were the other big addition. The interesting part isn't the button, it's the edge cases:

An e-mail is only trusted if the provider says it's verified.
Pre-account takeover is blocked. If someone registered your e-mail with a password but never verified it, and you then sign in with Google, the unverified password is wiped and its sessions are killed. Otherwise the squatter would still hold a way in.
Profile photos are downloaded once, only over HTTPS and only from Google or Facebook hosts, with every redirect re-checked (no SSRF), then re-encoded to WebP.
No access or refresh tokens are stored, and you can't disconnect your last way of signing in.

Security, layer by layer

A marketplace holds people's names, phone numbers and addresses, so security was part of the build from the first migration, not a feature bolted on at the end:

Passwords are hashed with Argon2id, and old bcrypt hashes upgrade on the next sign-in.
Sign-in has per-account and per-IP lockouts, six-digit e-mail codes, alerts for new devices, and "sign out everywhere else".
Bots meet four layers. A honeypot field. A signed form ticket: every page render carries a fresh, encrypted issue time, and a form that comes back too fast, hours later, or with a forged ticket is refused. (My first version trusted a timestamp from the browser, which a script can simply fake.) Invisible reCAPTCHA v3 scoring. And a visible challenge, Cloudflare Turnstile or the reCAPTCHA v2 box, on sign-up, contact and password resets, and on sign-in after a low score.
CSRF: every state-changing request carries a token, the token is regenerated on every full page load, and any write the browser marks as cross-site is refused before it reaches a controller.
XSS is handled by React's escaping plus a nonce-based Content-Security-Policy with a new nonce on every response, strict-dynamic, object-src 'none' and frame-ancestors 'self'.
SQL injection has nowhere to go: every query runs through prepared statements.
Uploads are shrunk and converted to WebP in the browser, then decoded and re-encoded on the server, which strips EXIF and GPS data and anything hidden after the pixels. SVG is refused.
Basket Buddy, the on-site assistant, is tap-only. It accepts whitelisted intent keys, never free text, so there's nothing to prompt-inject, and every personal answer is built from the signed-in user alone.
Floods hit a site-wide rate limiter on every page, with much tighter limits on sign-in, sign-up, search, checkout, payments and every write.

Designing for a real market morning

People open GleanGrid on a phone, often on mobile data, usually in a hurry. That set the priorities.

On phones the search bar gets its own row, categories sit in a scrollable rail with item counts, and the other filters open in a bottom sheet with Reset and Show results, so you set three filters and load once instead of three times. Every filter, search and page is a readable path rather than a query string (/products/category/fruits/price/100-500/sort/price-low), which is friendlier to share and to search engines.

Every product has a real photograph paired with a 3D illustration. The photo tells you what you're actually buying; the illustration keeps the catalogue recognisable at a glance. Product pages also chart the price over one, three or six months and say when today's price is below its 30-day average, and a seasonal calendar shows what's at its peak in Sindh this month.

The basket groups items by stall, because each stall becomes its own pre-order with its own pickup window. It shows the next pickup for every stall, lets you undo a removal, and keeps the total and the checkout button in a sticky bar on phones.

A few more details that matter more than they look:

Eight languages, including Urdu and Arabic, which flip the whole layout to right-to-left. Every locale has every key, checked by a script.
Search opens anywhere with Ctrl K, groups results into produce, farmers and markets, highlights matches and suggests "tomatoes" when you type "tomatos".
Stall badges (Top Rated, Reliable Pickups, Rising Star, Customer Favourite) are recalculated nightly. Top Rated uses a Bayesian average, so a stall with two five-star reviews can't outrank one with fifty 4.8s.
Motion with manners: headlines reveal word by word, items fly into the basket, two galleries slide sideways as you scroll. All of it switches off for anyone who prefers reduced motion.
Dark mode and an installable PWA with an offline page.

The farmer and admin side

Farmers aren't power users, so their panel is built around the three things they do every week: update stock, see what's been ordered, and hand it over.

Admins get a control room: today's orders, 30-day trends, pickups for the next week, revenue by market, catalogue health, a payments console with every payment's timeline and one-click refunds, and a sign-in security panel that flags IP addresses with repeated failures.

SEO and performance

Every page has a hand-written title and description, rendered on the server. Public pages carry linked structured data: Product with an offer that points at the stall selling it, LocalBusiness for stalls, Place with opening hours for markets, FAQPage for the help page, and a site search action. There's a live sitemap, sensible robots rules, and llms.txt / llms-full.txt for AI assistants that read the web.

Only English ships in the main bundle; every other language loads on first use. Maps load as they approach the viewport, images are WebP with responsive sizes, and fonts never block the first paint. Lighthouse gives the public pages 100 for accessibility, best practices and SEO.

Testing

133 PHPUnit tests with 779 assertions run against a real MySQL database and cover the order flow, payments, coupons, security headers, the bot and CSRF defences, structured data, race conditions and every role's pages.
Playwright end-to-end tests drive the real site as a visitor, a customer and an admin, on desktop and on a phone.
The stress script proves the concurrency guarantees with real parallel processes.
GitHub Actions runs all of it on PHP 8.2 and 8.3, plus a code-style check and a dependency audit, on every push.

How I worked, and where AI helped

I'll be straight about this, because I think it matters. I designed and wrote GleanGrid myself, and every decision in this article is one I made and can defend. I did use Claude as a second pair of eyes. It was genuinely useful for debugging, when I was staring at a failing test and needed someone to question my assumptions. It was useful for finding improvements, like pointing at a place where a lock was taken too late or a check trusted the browser. And it helped me tighten the documentation, which is the part of a project I'm most tempted to rush.

What it didn't do was replace understanding. The REPEATABLE READ bug is a good example. A suggestion is only worth something if you can explain why it's right, and I only trusted a fix once I could reproduce the failure with fifty processes and watch it disappear.

What I'd do next

If GleanGrid grew beyond a handful of markets, the next steps are clear. Redis for sessions, cache and rate-limit counters. A CDN in front of the images, with Cloudflare absorbing floods before they reach the server. WhatsApp alerts when an order is ready, because that's where people here actually read messages. And live Easypaisa and card acquiring, which plug into the same gateway interface JazzCash already uses once there's a merchant agreement.

What it taught me

The interesting problems were never the ones on the feature list. They were the questions in between. What happens when two people want the last item? What does the database see while a transaction is waiting? What happens if the payment gateway says yes twenty-one minutes later? What does a farmer need at six in the morning, with wet hands and one bar of signal? Building GleanGrid made me answer those properly instead of hoping they wouldn't come up.

If you run a market, sell at one, or just have thoughts on any of this, I'd genuinely like to hear from you. The source is on GitHub, and my inbox is open.

Find me across the web:

Portfolio: ahmershah.dev
Crunchbase: @syed-ahmer-shah
Crunchbase Company: @syedahmershah
Clutch: @syed-ahmer-shah
Tech Behemoth: @syed-ahmer-shah
Design Rush: @syed-ahmer-shah
Edverise: @syed-ahmer-shah
Trust Pilot: @ahmershah.dev
LinkedIn: Syed Ahmer Shah
GitHub: @ahmershahdev
AWS Builder Profile: @syedahmershah
DEV: @syedahmershah
Medium: @syedahmershah
Hashnode: @syedahmershah
Substack: @syedahmershah
HackerNoon: @syedahmershah
Substack: @syedahmershah
Facebook: @ahmershahdev
Linkedin Page: @syedahmershah
YouTube: @ahmershahdev
Instagram: @ahmershahdev
TikTok: @ahmershahdev

A Home on the Internet

Syed Ahmer Shah — Fri, 25 Sep 2026 15:47:36 +0000

For most of this year my writing lived in other people’s houses. An article went up on Hashnode, then DEV, then Medium, and my portfolio pointed at all of them with a small stack of cards that said “read more” and sent you somewhere else. I was a guest everywhere, and the one place with my name on the door had no room for the words.

That changed this month. I rebuilt ahmershah.dev from an empty folder and gave my writing a permanent address on it. Somewhere in the middle of that, Google started showing a knowledge panel when you search my name. This post covers all three, as plainly as I can, including the parts that aren’t finished yet.

What the old site was

The previous version is still public on GitHub as old_portfolio_v2. It was a static site: hand-written HTML, vanilla JavaScript with some jQuery, Bootstrap 5 for the grid, and Three.js loading a 3D Iron Man model into the hero. Some parts I was proud of at the time. There was a certificate flipbook built on Turn.js that you could actually page through, a dark and light theme toggle, a service worker so it kept working offline, and a contact form wired to EmailJS.

It also had the problems every hand-rolled static site collects. Forty-one stylesheets, each one patching something another one broke. More than thirty scripts that had to load in the right order or the page fell over. Every section was its own island, so changing the brand green meant a find-and-replace across the project and hoping nothing else matched.

And the blog wasn’t really a blog. It was a card stack of links to articles hosted somewhere else. The README listed “Blog integration with real articles (not just links)” under Upcoming Features. It never left that list.

None of that makes it a bad site. It was what I could build at the time, and it taught me exactly what I didn’t want to maintain for another year.

What ahmershah.dev is now

The new site is a Next.js 16 app on React 19, written in TypeScript and styled with Tailwind CSS v4. Motion runs on GSAP with ScrollTrigger, smooth scrolling on Lenis, and the hero scene is three.js through React Three Fiber. It deploys to Vercel from a private repository.

The stack isn’t what makes it better, though. The structure is.

One source of truth. My name, role, education, every certificate with its credential ID, the services, the client reviews: each lives once, in a typed content file. The pages render from those files. So does the structured data search engines read, and so does the small assistant in the corner of the site. When something changes, it changes everywhere, and I can’t accidentally tell Google one thing and a visitor another.

Phones get their own layout, not a shrunken one. Below the desktop breakpoint, three.js never downloads at all. The hero turns into a poster layout, the education timeline runs vertically, and the loader gets shorter. A phone on a slow connection shouldn’t pay for a 3D scene it can barely show.

Honest numbers. Lighthouse gives accessibility, best practices and SEO a score of 100 on every page type I tested, on mobile and desktop. Performance is where I have to be straight with you. The blog, article and legal pages score between 95 and 99 on desktop. The home page sits around 55 on desktop, and the mobile scores land in the high 50s and low 60s. The home page is one long document with every section in it, plus a WebGL scene. I chose that design knowing what it costs, and I’d rather show you the number than claim a perfect score.

There are small things too: interface sounds synthesized live in the browser instead of loaded from audio files, and a scroll-to-top button shaped like a pistol. I left a few jokes in for people who look closely.

The blog moved home

This is the part I care about most.

All 44 of my articles now live at ahmershah.dev/blogs as Markdown files inside the site itself. Code blocks are highlighted at build time. Each article has a table of contents, a reading time, tags, and a series if it belongs to one. There’s an RSS feed, a save-for-later list, a read-aloud mode that highlights each paragraph as it’s spoken, and a button to download any article as Markdown. This week I added a featured slot, pinned articles, sorting (latest, oldest, longest, quickest, A to Z) and an index view for scanning the whole archive at once.

Why bother, when free platforms already exist? Because the words are mine and should live at an address I control. Platforms change their rules, their paywalls and their feeds. If any one of them shut down tomorrow, nothing on ahmershah.dev would break, and no link I’ve shared would go dead.

How cross-posting works now

I’m not leaving the other platforms. DEV, Medium, Hashnode, CoderLegion and AWS Builder Center have readers I’d never reach alone, so every article still goes to them, sometimes reworded for the audience there.

What changed is the direction. New articles are published on ahmershah.dev first, and each copy elsewhere carries a canonical link back to the original. A canonical link is one line in a page’s head that tells search engines “the real version of this lives over there.” Without it, five copies of the same article compete with each other in search results. With it, the original gets the credit and the copies still get read.

The older articles are a different story, and I’ve kept them honest. Before this site had a blog, each piece was published first on DEV, Medium or Hashnode, and that’s where its canonical link still points. Its page here says so under the title, links to the original, and lists the other places it was shared. Relabelling those older posts as “originally on ahmershah.dev” would be rewriting history, and search engines would see through it anyway. The rule only runs forward: from this article on, the original lives here.

Why it isn’t open source (yet)

The old portfolio is public. This one isn’t, and that’s deliberate.

The site is new, and I’m still watching how it behaves on real phones, slow networks and browsers I don’t own. This week alone I fixed testimonial arrows that didn’t respond to taps on phones, service cards whose buttons were cut off on small screens, and a 404 page that deserved better than it had.

The biggest fix was email. The contact form used to hand messages to EmailJS from your browser, and it wasn’t reliable enough. It now goes through Resend: the email is sent from the server, from my own domain, after the form has been checked for spam. When you write to me, you get one confirmation that your message arrived and that I’ll reply within 2 to 4 working days. One email, not a newsletter.

Once the site has been stable for a while and I’ve cleaned up the parts I’m not proud of yet, I’ll think about opening the code. I’m not promising a date.

A knowledge panel with my name on it

The second piece of news is smaller than it sounds, and I want to describe it accurately.

When you search my name, Google now shows a knowledge panel: here it is. A knowledge panel is the information box Google shows for a person, place or organization it’s confident it understands, assembled from sources across the web. You can’t buy one or apply for one.

Google doesn’t explain why it creates a panel, so I can’t tell you exactly what did it. Here’s what I did that I believe helped:

The same name, photo and description everywhere. LinkedIn, GitHub, the writing platforms and the business listings all describe the same person in the same words.
One identity in the site’s structured data. Every page on ahmershah.dev refers to a single Person entry, and that entry lists every profile that belongs to me.
Consistent handles. @syedahmershah and @ahmershahdev on every platform where I could get them.
Writing under my own name, regularly, so there was something real for all of those profiles to point at.

I’ve since claimed the panel. Claiming means Google checked that I really am the person it describes, through my own verified accounts. After that I can suggest corrections when something in the panel is wrong or out of date.

What it doesn’t mean matters just as much. It doesn’t make me famous, and it isn’t an endorsement of my work. It means Google is confident who I am and which profiles are mine, and it lets me keep that description accurate. For someone early in their career that’s genuinely useful: a client who searches my name finds me, my work and my writing in one place, not a guess.

What’s next

Watch the new contact form deliver for a few weeks, and fix whatever real visitors find.
Keep every new article’s copies on DEV, Medium and Hashnode pointing back here.
Keep writing. The blog has room now.
Decide, later and without hurry, whether to open-source the site.

A portfolio used to be a brochure to me: something you glance at and leave. This one is closer to a home. The work lives here, the writing lives here, and everything else I have on the internet points back to it.

If something on the site breaks for you, tell me through the contact form. I read every message.

Find me across the web:

Portfolio: ahmershah.dev
Crunchbase: @syed-ahmer-shah
Crunchbase Company: @syedahmershah
Clutch: @syed-ahmer-shah
Tech Behemoth: @syed-ahmer-shah
Design Rush: @syed-ahmer-shah
Edverise: @syed-ahmer-shah
Trust Pilot: @ahmershah.dev
LinkedIn: Syed Ahmer Shah
GitHub: @ahmershahdev
AWS Builder Profile: @syedahmershah
DEV: @syedahmershah
Medium: @syedahmershah
Hashnode: @syedahmershah
Substack: @syedahmershah
HackerNoon: @syedahmershah
Substack: @syedahmershah
Facebook: @ahmershahdev
Linkedin Page: @syedahmershah
YouTube: @ahmershahdev
Instagram: @ahmershahdev
TikTok: @ahmershahdev

The Art of Object-Oriented Programming

Syed Ahmer Shah — Thu, 17 Sep 2026 18:31:03 +0000

Most developers learn OOP backwards — memorize four buzzwords, pass the exam, then go write procedural code inside classes. That’s not object-oriented programming. That’s just spaghetti with labels on it.

OOP is a design philosophy before it’s a syntax. It’s a way of breaking a complex system into smaller, self-contained pieces — pieces that each know their job, protect their own state, and can talk to each other without the whole thing falling apart. The syntax is easy. The thinking is what takes years.

Classes & Objects

A class is a blueprint. An object is the thing built from it.

Think of an architect’s floor plan for a house. The blueprint describes two bedrooms, a kitchen, a front door. But you can’t live in the blueprint. When a builder follows it and constructs an actual house — that’s the object. Build fifty houses from the same blueprint and each one is its own thing: different paint, different furniture, different family inside.

Same class. Two separate objects. This is the starting point.

State, Behavior & Identity

Every object carries three things: what it knows, what it can do, and what makes it uniquely itself.

State is the data — a bank account’s balance, a user’s email address. Behavior is the methods — a bank account can deposit, withdraw, generate a statement. Identity is what separates one object from another even if their data is identical. Two bank accounts with the same zero balance are still two separate accounts.

A constructor is where this all begins. It’s the object’s moment of birth — where you set up valid, usable initial state before anyone else touches it.

Good constructors do one thing: produce a valid object and get out. No database calls, no network requests, no side effects. Just state.

Methods are where responsibility lives — but the most important question about any method isn’t “does it work?” It’s “does it belong here?” A User class should not have a method called sendInvoice(). That's not the user's job. When a method doesn't belong, it's a signal that your boundaries are wrong.

The Four Pillars — What They Actually Mean

Encapsulation

Encapsulation is not “make things private.” That’s the mechanism. The principle is protecting your state from being changed in ways you didn’t intend.

Think of a vending machine. You can see the snacks through the glass, put money in, and press a button. But you cannot reach inside and grab whatever you want. The machine controls its own internals. You interact through a defined interface.

The stock field is private. No external code can set stock = 999. All changes go through purchase(), which enforces the rules. That's the point — not hiding data for its own sake, but controlling how it changes.

Abstraction

Abstraction hides complexity behind a simple interface.

When you drive a car, you don’t need to understand internal combustion to press the accelerator. The car abstracts all of that away. You get a pedal. You press it. The machinery underneath is none of your business.

The calling code just calls .charge(). It doesn't care how. Tomorrow you add a PayPal gateway. The calling code doesn't change. That's abstraction doing its job.

Inheritance

Inheritance captures the “is-a” relationship. A Dog is an Animal. A SavingsAccount is a BankAccount. You inherit the shared structure, then specialize.

Here’s where most people go wrong: they use inheritance for code reuse rather than for actual “is-a” relationships. If you’re inheriting from a class just to borrow two methods, you’ve built a dependency that’ll betray you when the parent class needs to change. Inheritance should model a genuine relationship — not be a shortcut.

Polymorphism

Polymorphism means the same interface, different behavior. One method name, many implementations depending on which object you’re actually calling it on.

printArea doesn't know or care whether it's working with a circle or a rectangle. It calls .area() and trusts the object to do the right thing. Add a Triangle tomorrow — printArea doesn't need to touch it. This is what makes systems extensible without becoming fragile.

Composition vs. Inheritance — The Choice Nobody Teaches Properly

Real OOP design lives in this question: should this object be the other thing, or should it have it?

A Car doesn't inherit from Engine. That would be absurd. A Car has an engine. It uses an engine. That's composition.

If tomorrow you need an ElectricEngine, you swap it in. The Car class doesn't change at all. Inheritance would have made that painful. Composition keeps it trivial.

The general rule: prefer composition. Use inheritance only when you have a genuine “is-a” relationship and you want to express that relationship explicitly in the design.

Association, Aggregation & Composition

These three describe how tightly objects are bound to each other — and it matters more than most tutorials acknowledge.

Association is the loosest connection. A Doctor treats Patients. They know about each other. Neither owns the other. They can both exist independently.

Aggregation is a whole-part relationship where the parts survive without the whole. A Team has Players. Dissolve the team, the players still exist somewhere.

Composition is the tightest bond — the part cannot exist without the whole. A House has Rooms. Destroy the house, the rooms aren't standalone things anymore.

Getting this right isn’t academic. It determines how you structure your database schemas, how you handle object lifecycles, and what breaks when something gets deleted.

Coupling & Cohesion — The Two Dials

Every system has two dials you’re constantly tuning.

Coupling measures how much one class depends on another. High coupling means a change in one class ripples into others, sometimes into five others you didn’t expect. Low coupling means classes can change independently. You want low coupling.

Cohesion measures how focused a class is on a single purpose. A class that handles user registration, sends confirmation emails, generates PDFs, and logs activity — that’s low cohesion. It’s doing four different jobs. When you split that into four focused classes, each becomes easier to test, easier to change, and easier to understand.

High cohesion and low coupling together produce modular code. A UserRegistrationService that only handles registration and receives its email sender and logger through injection rather than creating them — that's what well-designed OOP looks like in practice.

The question to ask every time you write a class: if I had to change this one thing, how many other places would break?

Common OOP Design Mistakes

A few patterns that feel right until they don’t:

The God Object. One massive class that knows everything and controls everything. Usually named Manager, Handler, or Utilities. This class grows without limit because "it's already there." Split it ruthlessly.

Anemic domain models. Objects that are just bags of data — nothing but getters and setters — with all the actual logic sitting in a separate service. This is procedural code wearing OOP clothes. Behavior belongs with the data it operates on.

Deep inheritance chains. Five levels deep, the sixth developer can’t understand what they’re actually working with. The deeper the chain, the harder it breaks. Flatten it with composition.

Abstracting too early. Building interfaces and abstract base classes before you have two real concrete variations. Write the concrete thing first. Abstract only when you see the pattern emerge from actual code — not from prediction.

A Small Real-World Example

Consider an order system. A bad design puts everything into Order: it calculates totals, applies discounts, sends emails, and updates inventory. Every time any one of those things changes, you're editing this one class.

A better design:

Three classes. Three clear jobs. Order knows its own data. DiscountService knows how pricing works. OrderNotifier knows how to reach the customer. None of them know too much about the others. Swap email notifications for SMS tomorrow — Order doesn't care, DiscountService doesn't care. Only OrderNotifier changes.

This is low coupling and high cohesion working together. It’s not clever. It’s disciplined.

Conclusion: OOP as a Design Mindset

OOP isn’t about memorizing four words. It’s not a style guide. It’s a discipline for managing complexity — for breaking a system that’s too big to hold in your head into pieces that each have a clear owner and a clear job.

The programmers who use it well think before they type. They ask: where does this knowledge live? Who is responsible for this behavior? What happens to the rest of the system if this changes? They treat their objects the way an architect treats walls — with respect for what they hold up.

Learn the concepts once. Then spend the rest of your time learning how they work together. The syntax is a day’s work. The design sense takes years. That’s where the actual art is.

References

Gamma, Helm, Johnson, Vlissides — Design Patterns: Elements of Reusable Object-Oriented Software
Martin Fowler — Refactoring: Improving the Design of Existing Code
Robert C. Martin — Clean Code: A Handbook of Agile Software Craftsmanship
MDN Web Docs — Object-Oriented Programming in JavaScript
Mattias Petter Johansson — Composition over Inheritance (FunFunFunction, YouTube)

Find me across the web:

Portfolio: ahmershah.dev
Crunchbase: @syed-ahmer-shah
Crunchbase Company: @syedahmershah
Clutch: @syed-ahmer-shah
Tech Behemoth: @syed-ahmer-shah
Design Rush: @syed-ahmer-shah
Edverise: @syed-ahmer-shah
Trust Pilot: @ahmershah.dev
LinkedIn: Syed Ahmer Shah
GitHub: @ahmershahdev
AWS Builder Profile: @syedahmershah
DEV: @syedahmershah
Medium: @syedahmershah
Hashnode: @syedahmershah
Substack: @syedahmershah
HackerNoon: @syedahmershah
Substack: @syedahmershah
Facebook: @ahmershahdev
Linkedin Page: @syedahmershah
YouTube: @ahmershahdev
Instagram: @ahmershahdev
TikTok: @ahmershahdev

GPT-6 Astra: A New Era of Machine Intelligence

Syed Ahmer Shah — Fri, 11 Sep 2026 13:51:57 +0000

Before I get into this, a quick apology — I’m a bit late to the party on writing this. My university semester just kicked back in and the first few weeks are always the kind of chaos that makes you forget you had things to write. But better late than honest, so here we go.

What Is GPT-6 Astra?

GPT-6 Astra is OpenAI’s newest and most powerful AI model. It was released on September 3, 2026, and OpenAI describes it as the most capable and aligned model they have ever broadly deployed. If you’re not familiar with the GPT model family, think of it like this — GPT-4 was the model that got everyone talking about ChatGPT, GPT-5 made it actually useful for serious work, and GPT-6 Astra is where OpenAI is now making a case that we might be at the edge of something called AGI, or Artificial General Intelligence. That’s a loaded term and we’ll get to it.

In OpenAI’s model lineup, Astra sits at the very top. Its predecessor, GPT-5.6 Sol, was released just weeks before in July 2026. Astra replaces it as the flagship.

The Launch

Astra launched September 3, 2026. Access started with a limited set of organizations on day one, then rolled out to ChatGPT Plus, Pro, Business, and Enterprise users over the following days. It’s also available through the OpenAI API, Microsoft Azure, and AWS Bedrock. The API model identifier is gpt-6-astra.

OpenAI president Greg Brockman called it a “generational leap” at launch and said it could eventually be seen as the arrival of AGI. That’s a bold thing to say out loud, and the tech community has been both excited and skeptical about it.

What Makes Astra Different?

The most technically interesting thing about Astra is something called recurrent depth, sometimes also described as “looped transformers.” Without going too deep into the math, traditional models predict the next word one step at a time. Recurrent depth allows the model to think internally before it outputs anything, looping through computations that aren’t visible as text. The result is that Astra uses roughly 65% fewer output tokens than its predecessor to do the same work, which makes it both faster and more cost-efficient on certain tasks.

The tradeoff? This internal reasoning is harder to monitor. OpenAI acknowledges that parts of Astra’s thought process are obscured, which is a legitimate safety concern some researchers have flagged.

The other major shift is that Astra is designed to be a computer operator, not just a text generator. It can open browsers, navigate interfaces, click through software, run code in live environments, and complete tasks that span multiple steps without you holding its hand through each one. This is what people mean when they say “agentic AI.”

Context window sits at 1,050,000 tokens with a max output of 128,000 tokens — same as GPT-5.6 Sol, so no expansion there, but the way Astra uses that context is reportedly more efficient. Knowledge cutoff is April 30, 2026.

Core Capabilities

Astra is described as state-of-the-art in several areas:

Reasoning and Planning — Astra can break down complex multi-step problems and actually carry them through. The UK AI Security Institute found Astra’s math time horizon without chain-of-thought monitoring was about 31 minutes, compared to 3.6 minutes for its predecessor. That’s a sign of significantly deeper planning ability.

Coding and Software Engineering — Astra is strong here, especially in agentic workflows where it can work inside a coding environment, test its own output, and fix errors without prompting. OpenAI calls it their best model for software engineering.

Computer and Browser Use — This is arguably where Astra has made the biggest jump. On the OSWorld 2.0 benchmark, which tests how well an AI can operate a computer, Astra completed tasks in around 40 minutes versus 75 minutes for GPT-5.6 Sol — roughly 47% faster.

Science and Mathematics — Astra scored 97.6% on FrontierMath Tier 4, which is a graduate-level math benchmark designed specifically to be hard for AI systems. It hit 96.0% on GPQA Diamond, covering biology, chemistry, and physics at the doctoral-question level.

Professional Work — Generating reports, building presentations, doing document analysis across hundreds of pages — Astra handles these workflows with more reliability than previous models.

Benchmarks: The Honest Picture

OpenAI’s own numbers are impressive. Astra scores 99.9% on ARC-AGI-3, 97.6% on FrontierMath Tier 4, and 100% on ExploitBench (the cybersecurity exploitation benchmark). Those headline numbers traveled everywhere when Astra launched.

Here’s the part most articles skip: the independent benchmarks tell a more complicated story.

On the Artificial Analysis Intelligence Index, an independent third-party aggregate, Astra scores 61.2 — effectively the same as GPT-5.6 Sol at 60.9, and behind Claude Fable 5.1 at 65.7. On coding specifically, Astra’s DeepSWE score sits around 74.1%, which is only about 1.4 points better than its own predecessor, and roughly tied with Claude Opus 5 and even some Gemini models.

The ARC-AGI-3 99.9% score also comes with a footnote — it was achieved using OpenAI’s own adapter harness, which preserves reasoning state between actions in a way the standard neutral testing harness doesn’t. On the standard harness, the same model scored 62.7%.

On Humanity’s Last Exam with tools, Astra scored 57.2%, behind Claude Fable 5.1 at 65.0%.

So what does this actually mean? Astra genuinely leads in computer use, advanced mathematics, cybersecurity, and speed. It does not dominate every single category, and in some areas Claude Fable 5.1 still holds the edge. The “world’s most intelligent model” claim is specifically OpenAI’s claim on OpenAI’s tables. Third parties tell you it’s competitive, not a clean sweep.

Real-World Uses

For developers — Astra inside Codex can write, test, debug, and iterate on code with less hand-holding. If you’re building something and want to offload repetitive engineering work, this is the practical use case.

For students and researchers — Long-context retrieval at over a million tokens means you can feed Astra entire research papers, textbooks, or codebases and ask it to synthesize, analyze, or answer questions across all of it.

For businesses — Multi-step professional workflows. Think document review, report drafting, slide creation, compliance checking — tasks that previously needed multiple separate tools or a lot of human time.

For automation — Astra’s computer-use capabilities mean it can be set loose on repetitive browser tasks, data entry, QA testing, and similar work that doesn’t need constant supervision.

Pricing and Access

API pricing is $10 per million input tokens and $50 per million output tokens. There’s also a Fast Mode that costs 2x the standard rate but delivers up to 2x the speed. Cached input (useful for developers sending the same context repeatedly) drops to $1 per million tokens.

For comparison, this is about 2.5x the price of GPT-5.6 Sol at its current promotional rate, and roughly on par with Claude Fable 5.1. For ChatGPT subscribers, Astra is included in existing Plus, Pro, Business, and Enterprise plans, with extra usage available via credits.

Where It Genuinely Shines — and Where It Doesn’t

Astra is strong in: computer and browser use, advanced math, long-context recall, speed over its predecessor, agentic multi-step tasks, and cybersecurity (with restrictions). On OpenAI’s internal hallucination benchmark, Astra’s error rate dropped from 12.2% (GPT-5.6 Sol) to 4.2% — that’s a meaningful reduction in the “making things up” problem.

Astra still struggles with: raw aggregate intelligence by independent metrics, some reasoning benchmarks where Claude Fable 5.1 leads, and tasks requiring complex creative judgment or deeply human nuance. Cost is also a real limitation — at $50 per million output tokens, running Astra through heavy API workflows adds up fast. And the cybersecurity capabilities that are most powerful are locked behind OpenAI’s vetted access program, not freely available.

The recurrent depth architecture also raises a monitoring concern that OpenAI itself acknowledges — some reasoning is hidden, making it harder to audit what the model was actually “thinking” when it made a decision.

Astra vs GPT-5.6 Sol

The honest upgrade: Astra is faster, hallucinates less, and handles agentic/computer-use tasks significantly better. On coding and general intelligence by independent metrics, the gap is small. If you’re a developer doing agentic work, the upgrade is worth it — Astra matches Sol’s task performance at lower token cost due to efficiency gains. If you’re doing conversational or standard writing tasks, the difference isn’t dramatic.

My Experience: The Video Editing Test

I had a chance to test Astra’s video editing capability. And I’ll say this straight — as an AI doing video editing, it’s honestly impressive that we’re even having this conversation. The ability to handle effects, add text overlays, composite images onto video, manage layers — it does all of that at a level that would have seemed like science fiction just a couple of years ago.

But there are gaps. The one that stood out most to me was sound effects syncing. I had a keyboard typing segment in a video, and the sound effect it placed for that just didn’t match — timing was off, the character of the sound didn’t fit the visual. It got the visual layer right. The audio layer was clumsy.

More broadly, I felt Astra handles introductory-to-intermediate video editing reasonably well, but mid-complex work — anything where timing precision, layered audio mixing, or scene-specific judgment calls matter — it starts showing its limits. It’s not a replacement for a real video editor with experience. It’s a surprisingly capable assistant that will save you time on the parts it can handle, while still needing you for the parts it can’t.

That gap is important. And it points to the broader message I want to land.

The Future — and Why You Shouldn’t Be Scared

The conversation around AI “taking over jobs” gets loud every time a model like this drops. I want to push back on that framing.

AI is a tool. A very powerful, increasingly capable tool — but a tool. The people who will lose ground are not the ones who use AI, but the ones who refuse to understand it. There’s a difference between someone who pastes code from ChatGPT without reading it, and someone who reads the code, understands what it’s doing and why, and then uses AI to move faster. The second person builds real skill. The first one just gets dependent.

My recommendation, especially if you’re a student or a developer just starting out — use AI consistently, but stay in the driver’s seat. When AI writes code for you, read it. When it generates a plan, interrogate it. When it makes an error, understand why it made it. The understanding is what compounds. The AI just accelerates it.

Astra, and whatever comes after it, represents genuine progress. AGI-level or not, these systems are getting better at autonomous, multi-step professional work at a pace that’s hard to ignore. The right response isn’t fear. It’s to get faster, sharper, and more grounded in what you actually know.

Final Verdict

GPT-6 Astra is a real step forward, particularly for agentic work, computer use, and advanced mathematics. It’s not the clean sweep the launch headlines suggested — Claude Fable 5.1 holds its own in aggregate intelligence, and the independent benchmarks paint a more competitive picture than OpenAI’s own tables.

If you’re a developer doing agentic or automation work, Astra is worth using. If you’re on ChatGPT Plus or Pro, explore it — the hallucination reduction alone is noticeable in daily use. If you’re evaluating it for heavy API workloads, the pricing is steep and should be modeled carefully before committing.

Is this a “new era of machine intelligence”? That depends on what the next 12 months look like. What I’ll say is that we’re somewhere different from where we were a year ago, and things are moving fast enough that the question might answer itself by the time anyone finishes reading this.

References

Find me across the web:

Portfolio: ahmershah.dev
Crunchbase: @syed-ahmer-shah
Crunchbase Company: @syedahmershah
Clutch: @syed-ahmer-shah
Tech Behemoth: @syed-ahmer-shah
Design Rush: @syed-ahmer-shah
Edverise: @syed-ahmer-shah
Trust Pilot: @ahmershah.dev
LinkedIn: Syed Ahmer Shah
GitHub: @ahmershahdev
AWS Builder Profile: @syedahmershah
DEV: @syedahmershah
Medium: @syedahmershah
Hashnode: @syedahmershah
Substack: @syedahmershah
HackerNoon: @syedahmershah
Substack: @syedahmershah
Facebook: @ahmershahdev
Linkedin Page: @syedahmershah
YouTube: @ahmershahdev
Instagram: @ahmershahdev
TikTok: @ahmershahdev

The New Era of Software Engineering

Syed Ahmer Shah — Fri, 04 Sep 2026 12:52:17 +0000

I'm Syed Ahmer Shah. I'm 19, I'm from Pakistan, and I'm still an undergraduate studying Software Engineering. I want to say that clearly before anything else, because I'm not writing this as some expert looking down from a mountain of experience. I'm writing this as someone who is in it right now, watching the ground shift under his own feet while still learning how to walk on it.

This is not a "10 years from now, robots will take your job" article. I don't know what happens in 10 years. Nobody does, not even the people running the biggest AI labs in the world, no matter how confident they sound on stage. What I do know is what happened to me in the last year, what I saw happen to a senior developer I worked under during my internship, and what I've watched happen across the entire industry I'm trying to build a career in. That's what I want to tell you about.

How It Used to Work

Before I get into AI, I want you to understand what software engineering actually was, because a lot of non-technical people imagine it as some kind of typing wizardry — fingers flying across a keyboard, green text on a black screen, hacker-movie stuff.

It was never that. Software engineering was closer to construction work, except the building was invisible.

You start with a problem. A bank wants an app so people can send money without visiting a branch. A restaurant wants a system to manage orders. A hospital wants patient records that don't get lost in a filing cabinet. The engineer's job was to take that vague human need and turn it into thousands, sometimes millions, of precise instructions that a machine could follow without ever getting confused, because machines don't tolerate confusion. A single misplaced comma could crash the entire system.

This meant a developer spent years learning the "grammar" of programming languages — Python, Java, JavaScript, C++ — the same way you'd spend years learning a foreign language before you could write a novel in it. Then on top of that grammar, you had to learn logic: how to break a huge problem into small enough pieces that a computer could handle each piece one at a time. Then you had to learn the tools around it — databases to store information, servers to run your program, version control so ten people could work on the same project without overwriting each other's work.

And then, once all of that was written, you had to test it, break it on purpose, find where it failed, and fix it. Debugging — hunting for the one wrong line in ten thousand — was often the most painful and most respected skill in the field. Senior engineers weren't senior because they typed fast. They were senior because they had, over years, built an instinct for where problems hide and how systems fail.

That was the job. Slow, deliberate, deeply manual. You earned your competence one bug, one late night, one confusing error message at a time. That was the world I entered when I chose this degree.

That world is not gone. But it is no longer the whole story.

Then the Machines Started Writing Code Too

Somewhere in the last two or three years, something changed that most people outside tech still haven't fully registered. AI coding tools stopped being toys that could autocomplete a line of code, and started becoming something closer to junior engineers you could actually talk to.

GitHub Copilot was one of the first tools that showed people this was even possible — it sat inside your code editor and suggested entire chunks of code as you typed, trained on an enormous amount of publicly written code. Then came tools like Cursor, which is basically an entire code editor rebuilt around AI from the ground up, letting you describe what you want in plain English and watch it write, edit, and restructure real files across a real project. Then Claude Code and OpenAI's Codex arrived, and these went even further — they don't just suggest code, they can plan a task, write across multiple files, run commands in a terminal, test what they built, notice their own mistakes, and fix them, almost like an actual teammate sitting next to you.

This is the part I need you to sit with for a second, especially if you're not from a tech background: these tools are no longer just "helping you type faster." They can take a task like "add a login page with email verification" and actually go do it — write the files, connect the pieces, and hand you something that mostly works, in minutes.

And the people who built this world are the ones telling us how far it's already gone. Google's CEO, Sundar Pichai, has said that well over 30% of the code at Google is now written by AI. Microsoft's CEO, Satya Nadella, has said something similar about his own company's codebase. Anthropic's CEO, Dario Amodei, predicted in early 2025 that the vast majority of code could be AI-written within a matter of months. Google's own AI leadership has talked about AI performing like a junior software engineer within a year. These aren't random influencers making noise for clicks. These are the people who literally run the companies building this technology, telling us — in public, on the record — that the ground has already moved. [1][2][3]

And then there's Ryan Dahl. If you're not from tech, that name might mean nothing to you, but in this industry it means a lot. Dahl created Node.js in 2009, a piece of technology that quietly powers a massive chunk of the modern internet — it's one of the reasons so many websites and apps you use every day even work. This isn't some junior developer with a hot take. This is one of the most respected engineers alive. And in early 2026, he posted something that spread across the entire developer world within hours: that the era of humans writing code by hand, line by line, is effectively over. He was careful to say this doesn't mean engineers have nothing left to do — but that the "writing syntax word by word" part of the job, the part most of us spent years training for, is no longer where the real work lives. [4][5]

When I read that, sitting in my hostel room in Pakistan, I felt something between excitement and a small, quiet panic. Because I knew exactly what he was talking about. I had already started feeling it myself.

My Own Trap

I want to be completely honest here, because I think this is the part that actually matters for anyone reading this who is learning to code right now, anywhere in the world.

When these tools got good, I got lazy. Not lazy in the sense of not working — I was working all the time, shipping code, finishing assignments, building projects fast. But lazy in a much more dangerous way. I would open an AI tool, describe what I wanted, and let it write the whole thing. It worked. It ran. I moved to the next task. I didn't read the code line by line. I didn't ask myself why a particular function was structured that way, or what a specific keyword was actually doing under the hood, or why the AI chose this approach over another one that might have existed.

For a while, this felt like progress. I was building things faster than my classmates. I was getting things done. But somewhere in the back of my mind, a quiet alarm kept going off. If someone asked me to explain the code I had just "written," could I actually explain it? Sometimes I could. But more and more often, the honest answer was no. I would stare at my own project and realize I understood what it did, but not how or why, not really — because I hadn't done the thinking. The AI had done the thinking. I had just done the asking and the copying.

That is a terrifying place to be as an engineer. Because the moment something breaks in a way the AI can't fix — and it will happen, because AI still makes confident mistakes, still misunderstands context, still writes code that looks correct but hides a subtle flaw — you're stuck. You don't have the foundation to even know where to start looking. I remember one specific night where a project I'd mostly "AI-built" broke in production-like conditions, and I sat there for almost two hours completely lost, not because the problem was that hard, but because I had never built the muscle to think through it myself. I had outsourced the muscle before I'd even built it.

That night was my turning point. I understood, very clearly, that if I kept going like this, I wasn't becoming a software engineer who uses AI. I was becoming a person who prompts AI and hopes for the best. And those are not the same thing, even if they can look identical from the outside for a while.

So I changed how I worked, deliberately and stubbornly. Now, before I let an AI tool write a single line for me, I make it explain itself first. What is it about to do? How is it planning to do it? Why this approach and not another? I go through this with it — sometimes it takes thirty, forty minutes before any actual code gets written — until I genuinely understand the plan well enough that I could, in theory, write it myself, just slower. Only then do I let the AI generate the code, and even then, I read every part of it like I'm grading someone else's homework, because in a sense, I am. It's slower. It's less flashy. But I walk away from every session actually knowing something I didn't know before, instead of just having a folder full of code I can't defend.

What I Saw During My Internship

This brings me to something that crystallized all of this for me — my internship at a software house called XCL.

There was a senior Laravel developer there, someone with real years of experience, working on a genuinely large, complicated codebase — the kind of project with so many moving parts that a beginner would get lost just trying to find where one feature lived. One day I asked him if he could walk me through how he actually works now, day to day. He said sure, and showed me.

What I watched was, honestly, a little surreal. He used Cursor almost constantly to write the actual code — describing what he needed, letting it generate large sections, adjusting as he went. Then, once a chunk of work was done, he would switch over to Claude specifically to review it — hunting for bugs, logic errors, things that didn't quite fit the rest of the system. He told me straightforwardly: this is what works for him now. Write with one tool, review with another, move fast, ship fast.

I remember standing there thinking two things at the same time, almost fighting each other in my head. The first was pure amazement — this man was moving through a massive codebase at a speed that would have taken a team of people years earlier. The second feeling was something closer to dread. Because if this is how a senior engineer with real, hard-earned experience works now — AI writes, AI reviews, AI fixes — then what exactly is left for someone like me, who's still learning, still building that foundation? Are we all just going to become prompt engineers, typing instructions into a box and hoping the box understands us well enough?

I sat with that question for a long time. I still don't have a perfect answer. But I've come to believe something, and I want to explain why.

Will Engineers Be Replaced?

Here's what I actually think, based on what I've read, what I've watched with my own eyes, and what I've lived through myself: software engineers are not being replaced. But the way we work is already changing, and it started changing a while ago, not in some far future.

Think about it like this. When calculators became common, accountants didn't disappear — but an accountant who could only add and subtract by hand, with nothing else to offer, became far less valuable than one who understood what the numbers actually meant for a business. The tool didn't remove the need for judgment. It removed the need for manual labor that judgment used to require. Something similar, but far more dramatic, is happening in software.

The parts of the job that were pure manual labor — typing out boilerplate code, remembering exact syntax, writing repetitive functions that follow known patterns — are being absorbed by AI, and honestly, good riddance to some of it. What's rising in value instead is exactly what AI still can't reliably do on its own: understanding what a business or a person actually needs and translating vague, messy human wants into a real system; making architectural decisions about how a large system should be structured so it doesn't collapse under its own weight two years later; knowing when the AI-generated solution is subtly wrong even when it looks perfectly fine on the surface; and taking responsibility when something breaks, because AI cannot be held accountable — you can.

Ryan Dahl himself made this same point when his statement went viral — he wasn't saying engineers are finished, he was saying the part of the job tied to typing syntax by hand is finished, and what remains is design thinking, decision-making, and reviewing and steering what the machine produces. That distinction matters enormously. [5][6]

So here's the honest, unglamorous truth I've landed on, and I say this as someone still figuring it out, not as someone who has it all solved: AI will not replace the engineer. But it will absolutely replace two specific kinds of people. First, it will replace the engineer who refuses to touch it at all, who insists on doing everything the old manual way out of pride or fear, because they will simply be too slow compared to everyone else in the industry. And second — and this is the one that scares me more, because I almost became this person — it will replace the engineer who depends on it completely, who never builds real understanding, who can prompt but can't think, and who becomes helpless the moment the AI gets something wrong, which it still does, regularly.

The survivors, I think, will be the people in the middle. People who use AI aggressively, without guilt, because refusing to use a tool this powerful would be its own kind of foolishness. But people who never let it replace the actual understanding in their own heads — who still ask why, who still read the code line by line, who still know enough to catch the AI when it confidently walks off a cliff.

What I'm Telling Myself, and Maybe You Too

I don't know exactly what software engineering will look like in five years. I don't think anyone genuinely does, no matter how certain they sound in interviews or on X. But I know what I'm choosing to do with my own hands, right now, at 19, while I still have time to build the right habits before they calcify into bad ones.

I use AI every single day. I'm not going to pretend otherwise, and I don't think anyone in this field honestly can anymore. But I use it after I understand the plan, not instead of understanding it. I let it write the boring parts fast, so I have more time to think about the parts that actually require thinking. And when something feels like magic — when the AI produces something that just works and I don't quite know why — I stop and I dig until I do know why, even if it costs me an extra half hour I didn't plan for.

That senior developer at XCL wasn't wrong to work the way he does. He's fast, he's effective, and he ships real, working software for real clients. But he got to that speed after years of understanding what "good code" even means, after years of debugging things by hand, after building the judgment that now lets him trust and check an AI's work in seconds instead of hours. I think that's the actual lesson hiding underneath all of this. The tools have changed. The starting point has not. You still have to understand before you can supervise. You just get to supervise something a lot faster and more capable than yourself, if you've earned the right to.

We're not becoming obsolete. We're becoming something else — something that doesn't fully have a name yet. Call it what you want. I just know I'd rather walk into that future understanding every step I take, even if it's slower, than sprint into it blind and find out too late that I never actually learned to walk on my own.

References

Reuters/company statements on AI-generated code at Google and Microsoft, as reported via CEO remarks from Sundar Pichai and Satya Nadella (2025).
Dario Amodei, Anthropic CEO, public remarks on projected AI coding capability, March 2025.
Jeff Dean, Google AI leadership, public remarks on AI performing at a junior-engineer level, May 2025.
Ryan Dahl (creator of Node.js and Deno), public post on X, January 2026 — reported by OfficeChai, "Era Of Humans Writing Code Is Over: Node.js Creator Ryan Dahl," https://officechai.com/ai/era-of-humans-writing-code-is-over-node-js-creator-ryan-dahl/
Reading.sh, "The creator of Node.js says the era of writing code is over," https://reading.sh/the-creator-of-node-js-says-the-era-of-writing-code-is-over-8320c868043b
EducationPost, "Era of humans writing code is over, says NodeJS creator Ryan Dahl," https://educationpost.in/news/technology/era-of-humans-writing-code-is-over-says-nodejs-creator-ryan-dahl

Tools referenced: GitHub Copilot (GitHub/Microsoft), Cursor (Anysphere), Claude Code (Anthropic), OpenAI Codex (OpenAI).

Find me across the web:

Portfolio: ahmershah.dev
Crunchbase: @syed-ahmer-shah
Crunchbase Company: @syedahmershah
Clutch: @syed-ahmer-shah
Tech Behemoth: @syed-ahmer-shah
Design Rush: @syed-ahmer-shah
Edverise: @syed-ahmer-shah
Trust Pilot: @ahmershah.dev
LinkedIn: Syed Ahmer Shah
GitHub: @ahmershahdev
AWS Builder Profile: @syedahmershah
DEV: @syedahmershah
Medium: @syedahmershah
Hashnode: @syedahmershah
Substack: @syedahmershah
HackerNoon: @syedahmershah
Substack: @syedahmershah
Facebook: @ahmershahdev
Linkedin Page: @syedahmershah
YouTube: @ahmershahdev
Instagram: @ahmershahdev
TikTok: @ahmershahdev