Get a quote

System Architecture · Beylikduzu

System Architecture for Beylikduzu businesses

Behind a sales floor a single stockroom can be all there is. The spare for the unit on display and the part promised to next week's scheduled maintenance wait on the same shelf. The promises, though, are made in two places: one at the desk, one in the service book. That is where the architectural question begins. Software architecture consulting in Beylikduzu turns on it: do you buy a second system to keep the two apart, or define two work types in one system? AlgoCar takes the second route, and stock moves because a work order says it does.

System Architecture — Beylikduzu

Beylikduzu's fabric leans on showrooms and sales floors, where a product meets its buyer on a display. If what you sold returns later as a service call, both jobs look at the same shelf. The closest work to that pattern is AlgoCar, our own product, whose upkeep we carry rather than hand over. Where it does not overlap goes first: written for a vehicle workshop, it is not a screen mounted on a display floor, we have nothing to show on furniture or textile, and production planning and the supply chain were never built into it. What travels is one decision: work types apart, record chain shared. Laravel sits underneath, with MySQL holding the records, Redis the cache, Inertia and Tailwind on the interface and React Native (Expo) in the field.

  • Scheduled maintenance and a service call are separate work types in the data model, yet both read one parts store, so no second stock record is opened.
  • A stock movement is not a step somebody types in; it is the consequence of a work order, falling the moment a part is written to that order.
  • Records and read load sit in separate layers: MySQL holds the records, Redis carries what is read often, and the interface reaches the same install through Inertia.

Why Algoriel

  • The parts read one source

    At Tahlil.com the site, the admin panel and the mobile app read the same information instead of behaving as three systems.

  • Where each job is solved comes first

    Which layer handles which job is decided before code, because work that has to move later is expensive to move.

  • The summary recomputes itself

    As the Günlük Hava Durumu archive grows, the climate summary recomputes from it; nobody maintains a monthly table by hand.

  • One rule for file layout

    On the KGM SsangYong site, where a file is written and under what name now follows one rule the upload code obeys.

  • Where the data divides

    When several institutions share one system, each enters through its own domain and student, guardian and payment records stay inside that institution's boundary. This arrangement is what the term multi-tenant describes.

  • What a record attaches to

    Whether service history is written against a person, an address or a device is settled before the schema exists. Reversing that later means re-attaching everything already recorded.

  • Permission held in the data model

    A teacher, a guardian and an institution administrator reach the same timetable record at their own level of access. Permission is part of how the record is defined, not a view switched off on a screen.

  • Splitting the read path

    Which screens are served from a held copy and which go to the database is settled before the first record exists. On Vipkurum a frequently opened screen comes from the copy, and only a read with no copy reaches the database.

  • Interfaces on a single system

    Tahlil.com hangs three interfaces off one system: the patient site, the physician panel and the mobile app read the same record, and no second data model is written per interface.

  • Storage laid out on day one

    The naming and folder scheme files will live under is fixed at the start; a layout imposed afterwards turns into a migration.

Work like this

System Architecture · Case study

AlgoCar — two work types in one system, stock moves off the work order

Our own product: a service system whose upkeep we carry, not a handover. It was built around the vehicle in the workshop. A work order opens, the part consumed is written to it, and the invoice comes off the same record. Warehouse movement waits on no separate screen; stock falls as the consumption is written. Scheduled maintenance and service calls run as distinct work types while both read one parts store. Maintenance history hangs off the plate and chassis record, AlgoCar's vehicle context; the record's shape is what travels. Laravel, MySQL and Redis underneath, Inertia and Tailwind on screen, React Native (Expo) in the field.

Read the case study →

Working with Beylikduzu teams, remotely

We have no office, so work for this city runs remotely and we do not offer on-site support. What was done, and why it was done that way, stays in writing. The project pages mark which builds came out of a partnership.

  • The first release ships as a working piece; extras follow later.
  • Every client we know of is in Turkey.
  • Decisions stay in writing; progress shows in working screens.

Frequently asked

  • Could we not buy two programs, one for each kind of job?

    You could, and then one shelf would keep two ledgers. If a part is typed into the service program and again into the maintenance program, the right figure only appears once somebody reconciles them at month end. In one system the kind of job is a field and the store stays single.

  • We do not run a vehicle workshop. What does AlgoCar tell us?

    AlgoCar was written for vehicle servicing and we say so plainly. What reaches you is not a screen but a decision about where a movement is recorded: stock falls because a part was written under a job. Put a fixed unit or a production line where the vehicle stood and that decision holds.

  • Would you also build the screen for our display floor?

    That is not the work described here. AlgoCar is service software; a presentation screen on a display floor or a shop catalogue falls outside it. What we can show is the record behind the counter: the job, the part and the commercial side.

  • Should you not visit our sales floor and watch the process?

    We keep no office and the work runs remotely. What comes out of the decision is writing rather than a screen: which kind of job lands on which record, at what moment stock moves, where the figure for a job closes. We write those down together, and code follows.

Let us settle where your data divides before any code is written.