Scorptech SolutionsScorptech
Contact Start a Project
Start a Project
contact@scorptechsolutions.com +91 91733 99077

Ahmedabad, Gujarat, India

LinkedIn GitHub X

Home/Insights

Notes from
inside the build.

Architecture decisions, modernisation playbooks and lessons from shipping software for clients across four sectors. Written by the people doing the work.

5

Briefs

54

Minutes

5

Topics

No article pages yet. Each entry below opens its working brief in place — the position, the argument for it, and the table we would put on a whiteboard.

FeaturedArchitecture

Designing a store around its catalogue

Most e-commerce builds do not fail at the checkout. They fail on a collection model that cannot express how buyers search, on identifiers nobody indexed, and on a theme carrying twelve apps it never needed. Here is the order we work in instead.

12 MIN READ SCORPTECH ENGINEERING Article in preparation
Open the brief See the build it came from
Catalogue pipeline 01 SOURCE DATA part numbers · OEM codes what buyers type 02 COLLECTION MODEL collections · variants modelled first 03 METAFIELDS cross-reference table five OEM brands 04 SEARCH INDEX indexed on identifiers either number hits 05 PRODUCT PAGE quote list, not a cart price the same day

The index

Five briefs from work in progress.

A brief is the article before it is an article: the position, the argument for it, and the table we would put on a whiteboard. Open one in place — none of these lead anywhere else yet.

Read for

Every brief. Fifty-four minutes if you read all five.

Three briefs on choosing a shape before you commit to it — the domain model, the service boundary, the message contract.

Two briefs on changing a system that is already carrying load, without stopping it.

Two briefs on the delivery side — who decides, how often you ship, and who is still there after launch.

E.01
Architecture

Designing a store around its catalogue

Why the collection model, not the checkout, decides whether an e-commerce build holds up at scale.

Model the collections, the variants and the cross-references before anyone opens the theme.

12 MIN READ Open brief Close

The argument

A checkout is a solved problem. A catalogue is not. Stores fail on a collection model that cannot express how a buyer narrows down — by part number, by OEM code, by the model of the machine it goes into — and on identifiers nobody thought to index. By the time it shows, the theme is already built on the wrong shape, and the fix is a migration rather than a patch.

So the order is fixed: source data and one canonical identifier, then collections, variants and metafields, then a search index over the identifiers buyers actually type, and only then the storefront — written in Liquid against sections we own, not a marketplace theme bent out of shape.

Order of work

StageWhat is decidedWhat breaks if it is skipped
Source dataWhich identifier is canonical.Two spellings of one part, and no match.
Collection modelHow a buyer narrows down.Filters that cannot express the question.
MetafieldsCross-references between brands.An OEM code that finds nothing.
Search indexWhat is searchable at all.Buyers falling back to phoning you.
ThemePresentation, and nothing else.Nothing, if the four above are right.

Swipe the table →

Full article in preparation Ask for the draft
E.02
Systems

Microservices vs modular monoliths

A decision framework based on team size and release cadence, not on what is fashionable.

Split on team boundaries and release cadence. Never on a diagram of nouns.

9 MIN READ Open brief Close

The argument

The question gets asked as architecture and answered as organisation design. Services buy one thing — the ability to deploy independently — so a single team that splits has bought a distributed system and paid for it in network calls, partial failure and a debugging story spread across four log streams.

A modular monolith gets the same discipline: enforced boundaries, one dependency direction, one deploy. It also leaves the door open, because a well-bounded module is the easiest thing to lift out later, and an entangled one was never going to become a clean service anyway.

What actually decides it

SignalPoints to a monolithPoints to services
Teams shipping independentlyOne or two.Three or more, separate roadmaps.
Release cadenceOne train, and nobody minds.Teams that must not wait for each other.
Data couplingOne transactional boundary.Genuinely separable ownership.
Ops maturityNo on-call rota yet.Tracing, dashboards and a rota in place.
Blast radiusA shared failure is acceptable.One component must fail alone.

Swipe the table →

Full article in preparation Ask for the draft
E.03
Engineering

Building reliable event-driven architectures

Idempotency, ordering and replay — the failure modes teams discover too late.

Assume every message arrives twice, out of order, and again next Tuesday.

14 MIN READ Open brief Close

The argument

Events decouple the producer from the consumer, which is the point, and also decouple the producer from ever knowing whether anything worked, which is the cost. The design therefore starts at the failure modes rather than at the happy path.

Every consumer is idempotent on a key the producer owns. Ordering is either not required or enforced per partition key, and which one it is gets written down. Replay is a supported operation with a dry run in front of it, not an emergency. An integration that fails loudly is worth more than one that quietly drifts.

Four failure modes

FailureWhere it shows upWhat we do about it
Duplicate deliveryThe order placed twice, the email sent twice.Idempotency key on a producer-owned id, stored with the result.
Out of orderA status that goes backwards.Ordering per partition key, or a version on the payload the consumer compares.
ReplaySix months of side effects re-fired.Dry-run consumer first, side effects behind a replay flag.
Poison messageA queue that stops moving.Bounded retries, then a dead-letter queue somebody actually reads.

Swipe the table →

Full article in preparation Ask for the draft
E.04
Modernization

Modernizing legacy PHP and Java platforms

A strangler-fig playbook for moving off an old monolith without a feature freeze.

No feature freeze. The old system keeps earning while the new one takes over route by route.

11 MIN READ Open brief Close

The argument

The rewrite that stops the business for nine months is the one cancelled at month seven. So we do not rewrite. A routing seam goes in front of the old application, one bounded capability moves behind it at a time, and the two run side by side until the old one has nothing left to serve.

Which capability goes first is a business decision, not a technical one: the one where the old system hurts most and the data boundary is cleanest. Slower on paper, considerably faster in practice, because the business never has to stop.

Strangler-fig order of operations

StepWhat movesHow you know it worked
1 · SeamNothing yet. A router in front.Traffic unchanged, and the logs now show every route.
2 · CharacteriseStill nothing.The routes nobody has called in a year are on a list.
3 · First capabilityOne bounded module.Old and new agree on every request for a week.
4 · Cut overThe router points at the new one.Rollback is one configuration change.
5 · RepeatThe next capability.The old route list gets shorter every month.

Swipe the table →

Full article in preparation Ask for the draft
E.05
Practice

What makes a great engineering organization

Notes from five years of embedding small senior teams inside client organisations.

Fewer people, for longer, with the authority to say no.

8 MIN READ Open brief Close

The argument

Five years of embedding small senior teams inside client organisations, and the pattern barely varies. The teams that ship are small, stable, and have someone empowered to decline work. The ones that do not are larger, rotate, and have four stakeholders each owning a quarter of a decision.

The mechanics are unglamorous: one project manager who stays rather than a handover between departments, a working demo on a real staging URL every sprint, and decisions written down — because the best system is the one your next developer can understand without us in the room.

Signals

What we look atHealthyStruggling
Decision rightsOne person can say no.Four stakeholders each own a quarter.
Demo cadenceA working URL every sprint.A demo when it is ready.
Team stabilityThe same team next quarter.A team that rotates on contract boundaries.
Written recordDecisions written down.Decisions in someone's head.
MaintenancePlanned work with a budget.What happens after an incident.

Swipe the table →

Full article in preparation Ask for the draft

Positions

Five arguments we will make on your project.

The same opinions, stated as decisions rather than as topics. If you disagree with one of them it is worth saying so before we start, rather than in month four.

The decision

The usual default

Our position

Where we argue it

The decision

How do we split the system?

The usual default

Microservices, because that is what scale is supposed to look like.

Our position

Team size and release cadence decide the split. One team shipping one product gets a modular monolith with enforced boundaries.

Where we argue it

E.02

The decision

Where does an e-commerce build start?

The usual default

With the theme and the checkout.

Our position

With the catalogue. Identifiers, collections and search come before a pixel of storefront.

Where we argue it

E.01

The decision

How do we replace the legacy platform?

The usual default

A rewrite, with a feature freeze while it happens.

Our position

A strangler fig. The new system in front, one capability at a time, no freeze and a way back at every step.

Where we argue it

E.04

The decision

What do we do about duplicate events?

The usual default

Handle it if it turns out to be a problem.

Our position

Every handler is idempotent from the first one. Replay is a normal operation, not an incident.

Where we argue it

E.03

The decision

How big should the team be?

The usual default

As many people as the deadline seems to need.

Our position

Small and senior, accountable to one roadmap, and still on the project after launch.

Where we argue it

E.05

Coverage

What we have written, and what we have not.

Six capabilities and the practice that runs them, against five briefs. Two rows have nothing on them, which is the honest answer to what is missing.

Capability E.01
Catalogue, designing a store around its catalogue		 E.02
Boundaries, microservices versus modular monoliths		 E.03
Events, building reliable event-driven architectures		 E.04
Legacy, modernizing legacy PHP and Java platforms		 E.05
Teams, what makes a great engineering organization
Web & Platform Engineering not covered covered not covered covered not covered
Mobile EngineeringNothing yet not covered not covered not covered not covered not covered
Product DesignNothing yet not covered not covered not covered not covered not covered
APIs & Integrations not covered not covered covered not covered not covered
Cloud & DevOps not covered covered covered not covered not covered
E-commerce & Shopify covered not covered not covered not covered not covered
Team & process not covered not covered not covered not covered covered

Swipe the matrix →

Two capabilities have nothing written against them. Those are the two we owe you, and they are what gets written next.

See all six capabilities

Publishing

No CMS behind this yet.

These five briefs are written and edited. What does not exist is an article route to hang the long version on, so nothing on this page links to a page that is not there. Every link here goes somewhere real — to another brief on this page, or to work you can read.

There is no newsletter and no content calendar either. A piece gets written when a project teaches us something we would have wanted to read a year earlier, by the engineer who did the work, reviewed by one other person on the team. That is why there are five and not fifty.

Now · five briefs Next · long-form routes Then · a feed worth having

Written in Ahmedabad · five subjects · no sponsored posts

Ask a question

Want the long version of one of these?

Say which brief and we will send the working draft. It is the same material we put in front of a client team when we are arguing for one of these decisions — an architecture review, a second opinion on a rebuild, or a sanity check on a proposal you have been handed.

Ask for a draft contact@scorptechsolutions.com

Free consultation · reply in one business day

Have a difficult problem?

Let’s turn it into a product worth building.

Start a Conversation contact@scorptechsolutions.com

Free consultation · reply in one business day · +91 91733 99077