Get a quote

System Architecture · Catalca

System Architecture for Catalca businesses

A printed sheet holds paper, not structure, and that is the condition behind the first architectural decision in Catalca. On a booklet page only the white space says where one question ends and the next begins; no field name and no row identity exists anywhere on it. So the architectural question comes first: who produces the structure? In the tool we wrote for Vipkurum, image processing draws the boundary. OpenCV divides the page into single questions, and where the cut falls is never left to a language model's reading, so the same page cuts the same way twice.

System Architecture — Catalca

Catalca's fabric is food retail and rural commerce. If your record keeping still begins on a printed document, the first question is who produces the structure inside it. This is also the one district we can name beside a real client: we wrote the QR menu for Merkez Kasap. That job was a menu page, though, and it is not the evidence behind this one. The evidence is Vipkurum's question cropping tool, and its limits are plain: written for education technology, with nothing to show for farming, livestock or food production processes, and no ordering or stock layer built into it. What we describe is how responsibility gets divided. Python and OpenCV carry the image work, Gemini and OpenAI models carry the meaning, records sit in MongoDB, Node.js calls the service, and content management stays on Laravel.

  • Image processing draws the boundary: OpenCV divides a page into single questions, and running the same page again cuts it in the same place.
  • Determinism and interpretation live in separate components, so code computes the geometry, a model resolves the meaning, and neither takes over the other's job.
  • The image service keeps a runtime of its own and reaches Laravel content management through Node.js, so the Laravel side never has to carry Python.

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

Vipkurum question cropping — OpenCV draws the boundary, a model reads meaning

A page of a question booklet is split into single questions by image processing. OpenCV decides where the cut falls, and because that decision is never handed to a model, reprocessing the same page yields the same result. Meaning is handled elsewhere: Gemini and OpenAI models bind the answer from the key to its question, so the key stops being a separate sheet and lands inside the cropped question's own record. Questions already held can serve as examples, and a new one is produced together with its answer. Images and question records sit in MongoDB, Node.js calls the Python service, and content management stays on the Laravel side.

Read the case study →

Working with Catalca 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 a language model not do the cropping directly?

    It could, but not repeatably. Looking at the same page twice, a model may shift the cut, and a shifted cut damages the question record. When OpenCV computes the geometry the result comes out identical every run, and the model stays on the meaning side.

  • Our booklets are scanned images and carry no structure. Where do you start?

    Carrying none is expected, because the structure is not in the page but in the image of it. The first decision is which information comes out of the image and which comes from a person: boundary and order come from the image, while subject and learning outcome are written into the record from outside.

  • Do you actually work with anyone in Catalca?

    Yes, and it is the only place in this network where that is true: we wrote the QR menu for Merkez Kasap and it is live in the district. That job was a menu page, though, so it proves nothing about the image processing architecture described here. Our Vipkurum work does.

  • Could you read farming or livestock records the same way?

    We have built nothing in those fields, so we promise nothing there. What we can describe is how a boundary printed on a page becomes a record; any work needing domain knowledge is built on top of that, separately.

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