Σχεδιασμός Συστήματος σε Nutshell

Ας ξεκινήσουμε. Είχα αυτό το άρθρο στο μυαλό μου για 2 χρόνια και ποτέ δεν το έγραψα, ανησυχώντας ότι δεν θα ήταν τέλειο. Το τεχνολογικό τοπίο αλλάζει συνεχώς και εξελίσσεται και τα εργαλεία που χρησιμοποιείτε σήμερα μπορεί να είναι ξεπερασμένα 5 χρόνια αργότερα. Αυτός είναι ο λόγος για τον οποίο γράφω τις βασικές έννοιες του σχεδιασμού συστήματος εδώ. Μπορούμε πάντα να το προσαρμόσουμε με βάση την υποδομή και τις απαιτήσεις μας. Αν συναντήσω ένα άλλο πλαίσιο, θα το γράψω ως συνέχεια αυτής της αλληλογραφίας. Ο σχεδιασμός συστήματος είναι ένα απαραίτητο μέρος της ανάπτυξης λογισμικού. Πρέπει να έχετε μια προβολή 30.000 ποδιών πριν σκάψετε σε συγκεκριμένα στοιχεία. Γλώσσες προγραμματισμού γενικού σκοπού μπορούν να χρησιμοποιηθούν παντού, αλλά πρέπει πρώτα να ξέρετε πού να το χρησιμοποιήσετε και πώς να το χρησιμοποιήσετε. Τα παρακάτω είναι τα σημαντικά βήματα που συνάντησα κατά τη διάρκεια της έρευνας μου (μερικά θέματα δεν θα εξηγηθούν λεπτομερώς καθώς αξίζουν το δικό τους άρθρο): UX Σχεδιασμός & Στοιχεία Δεδομένου ότι πιθανότατα δεν θα αναπτύξετε CLI, η ύπαρξη καλής UX-UI είναι σημαντική. Πρέπει να γνωρίζετε τα σημαντικά στοιχεία και στη συνέχεια να τα βελτιώνετε καθώς προχωράτε. Ένας κλώνος του Twitter θα έχει ένα στοιχείο όπου συντάσσονται τα tweets. θα έχει προφίλ χρηστών, οπαδούς, ρυθμίσεις απορρήτου κ.λπ. Ένας κλώνος της Uber θα έχει ενσωμάτωση χαρτών. Οι αγγελιοφόροι συνομιλίας όπως το WhatsApp θα έχουν μηνύματα πρόσωπο με πρόσωπο και μηνύματα ομάδας, επιλογές προώθησης και κοινής χρήσης κ.λπ. Προσπαθήστε να κατηγοριοποιήσετε τις εφαρμογές που σχεδιάζετε και να παρατηρήσετε το σχεδιασμό τους. όλες οι εφαρμογές κοινωνικών μέσων θα πέσουν κάτω από μια ομπρέλα, όλες οι πλατφόρμες ροής βίντεο / OTT σε μια άλλη, και όλες οι εφαρμογές κράτησης ταινιών / κρατήσεων θα πέσουν κάτω από μια άλλη. ╔═════════════════════════════════════╗ ║ TWITTER CLONE UI COMPONENTS ║ ╠═════════════════════════════════════╣ │ APPLICATION UI │ ├─────────────────────────────────────┤ │ ┌──────────┐ ┌──────────┐ │ │ │ Profile │ │ Tweet │ │ │ │Component │ │Component │ │ │ └──────────┘ └──────────┘ │ │ ┌──────────┐ ┌──────────┐ │ │ │ Settings │ │ Messages │ │ │ │Component │ │Component │ │ │ └──────────┘ └──────────┘ │ └─────────────────────────────────────┘ Κλάσεις / Υποκατηγορίες Εάν σκέφτεστε ένα σχεδιασμό προσανατολισμένο σε αντικείμενα, είναι ευκολότερο αν απαριθμήσετε όλες τις διάφορες κατηγορίες που μπορεί να χρειαστείτε στο σχεδιασμό του συστήματός σας. Αυτό βοηθά στην εξάλειψη όλων των αντικειμένων και στη συνέχεια μπορείτε να προχωρήσετε στον καθορισμό μεθόδων που σχετίζονται με αυτές τις κατηγορίες. ╔═════════════════════════════════════╗ ║ OBJECT-ORIENTED CLASS DESIGN ║ ╚═════════════════════════════════════╝ ┌─────────────────┐ │ User │ ├─────────────────┤ │ - name │ │ - location │ │ - email │ ├─────────────────┤ │ + post() │ │ + follow() │ └────────┬────────┘ │ ┌────────┴────────┐ │ │ ┌───▼────┐ ┌─────▼───┐ │Premium │ │ Basic │ │ User │ │ User │ └────────┘ └─────────┘ Σχεδιασμός Patterns Μόλις έχετε το σχεδιασμό της κατηγορίας, μπορείτε στη συνέχεια να επιλέξετε ένα κατάλληλο πρότυπο σχεδιασμού που εξυπηρετεί τις ανάγκες σας. Για παράδειγμα, εάν η εφαρμογή σας έχει μια ροή ειδήσεων, μπορείτε να εξετάσετε το πρότυπο σχεδιασμού Publisher-Subscriber. ╔═════════════════════════════════════╗ ║ PUBLISHER-SUBSCRIBER PATTERN ║ ╚═════════════════════════════════════╝ ┌──────────────┐ │ Publisher │ │ (News Feed) │ └──────┬───────┘ │ │ publish() │ ┌───▼────────────────┐ │ Message Broker │ └───┬────────────────┘ │ │ notify() │ ┌───┴───┬───────┬────────┐ │ │ │ │ ┌──▼──┐ ┌──▼──┐ ┌──▼──┐ ┌───▼─┐ │Sub1 │ │Sub2 │ │Sub3 │ │Sub4 │ └─────┘ └─────┘ └─────┘ └─────┘ CDN / Serverless / API / Cache CDN is used to host static HTML content with lower latency. You can incorporate it in your infrastructure to reduce response time. You can reduce costs by using serverless architecture for simple grunt work, automation, or cron jobs. APIs help a lot in connecting disconnected systems and enabling segregation of concerns. Cache helps store temporary data, but the catch is that cache memory is the most expensive type of memory. So, you must have an optimized cache strategy. ╔═════════════════════════════════════╗ ║ CDN/SERVERLESS/API/CACHE STACK ║ ╚═════════════════════════════════════╝ ┌─────────┐ │ Client │ └────┬────┘ │ ▼ ┌─────────────┐ ┌──────────┐ │ CDN │◄───│ Static │ │ (Static) │ │ Content │ └────┬────────┘ └──────────┘ │ ▼ ┌─────────────┐ ┌──────────┐ │ Cache │◄───│ Hot │ │ │ │ Data │ └────┬────────┘ └──────────┘ │ ▼ ┌─────────────┐ ┌──────────┐ │ API │◄───│Serverless│ │ Gateway │ │Functions │ └────┬────────┘ └──────────┘ │ ▼ ┌─────────────┐ │ Backend │ │ Server │ └─────────────┘ Συνεκτικότητα vs. συναλλαγματική συνέπεια In eventual consistency, you can expect some delay in the transaction being considered "written." This is used in applications where a little delay may not affect the overall application. For example, a WhatsApp message may be delivered with a delay of 2-3 seconds, and that should not impact the overall user experience. You can use a NoSQL database to achieve this. In transactional consistency, you want the transaction to be committed instantly. For example, in a money transfer application, you want the money transferred immediately to reduce the risks of double spending. You can use a relational database to achieve this. ╔═════════════════════════════════════════════════════════════╗ ║ EVENTUAL vs TRANSACTIONAL CONSISTENCY ║ ╚═════════════════════════════════════════════════════════════╝ EVENTUAL CONSISTENCY TRANSACTIONAL CONSISTENCY ┌──────────────────┐ ┌──────────────────┐ │ Write Request │ │ Write Request │ └────────┬─────────┘ └────────┬─────────┘ │ │ ▼ ▼ ┌─────────┐ ┌─────────┐ │ NoSQL │ │ SQL │ │ DB │ │ DB │ └────┬────┘ └────┬────┘ │ │ ┌────▼────┐ ┌────▼────┐ │ Delay │ │Immediate│ │ 2-3 sec │ │ Commit │ └────┬────┘ └────┬────┘ │ │ ▼ ▼ [Eventually [Immediately Consistent] Consistent] Εκδήλωση Δράση Η διαχείριση συμβάντων είναι απαραίτητη όταν έχετε διαφορετικά στοιχεία που προσπαθούν να μιλήσουν μεταξύ τους.Από την έναρξη του αιτήματος έως την εκπλήρωση της απάντησης, πρέπει να γνωρίζετε σαφώς τις διαδρομές που θα ακολουθήσουν τα πακέτα δεδομένων. ╔═════════════════════════════════════╗ ║ EVENT HANDLING FLOW ║ ╚═════════════════════════════════════╝ ┌──────────┐ Event ┌──────────┐ │Component │─────────────►│ Event │ │ A │ Fired │ Queue │ └──────────┘ └─────┬────┘ │ ┌─────▼─────┐ │ Handler │ └─────┬─────┘ │ ┌───────────┼───────────┐ │ │ │ ┌───▼───┐ ┌───▼───┐ ┌───▼───┐ │Comp B │ │Comp C │ │Comp D │ └───────┘ └───────┘ └───────┘ SQL / NoSQL / Πολύγλωσση επιμονή Σε κατανεμημένα συστήματα SQL, κατά τη διάρκεια των διαχωρισμών δικτύου, συνήθως δίνετε προτεραιότητα στη συνοχή έναντι της διαθεσιμότητας. Οι βάσεις δεδομένων NoSQL μπορούν να χρησιμοποιηθούν για την αποθήκευση ημι-διαρθρωμένων δεδομένων, ζευγαριών τιμών κλειδιών, εικόνων και βίντεο. Οι βάσεις δεδομένων γραφικών και οι βάσεις δεδομένων μηχανών αναζήτησης περιλαμβάνονται επίσης στις βάσεις δεδομένων NoSQL. Σε κατανεμημένα συστήματα NoSQL, συνήθως δίνετε προτεραιότητα στη διαθεσιμότητα και την ανοχή διαχωρισμού, αποδέχοντας την ενδεχόμενη συνέπεια. Σύμφωνα με το θεωρητικό CAP, σε ένα κατανεμημένο σύστημα που βιώνει διαχωρισμούς δικτύου, πρέπει να επιλέξετε μεταξύ συνέπειας και διαθεσιμότητας. Εάν χρειάζεστε έναν συνδυασμό βάσεων δεδομένων SQL και NoSQL, το ονομάζουμε πολυγλωσσική επιμονή. ╔═════════════════════════════════════╗ ║ SQL/NoSQL/POLYGLOT PERSISTENCE ║ ╚═════════════════════════════════════╝ ┌─────────────────────────────────────┐ │ Application Layer │ └──────────────┬──────────────────────┘ │ ┌───────┴────────┐ │ │ ┌──────▼──────┐ ┌─────▼────────────┐ │ SQL │ │ NoSQL │ │ Database │ │ Database │ ├─────────────┤ ├──────────────────┤ │ - ACID │ │ - Key-Value │ │ - Structured│ │ - Document │ │ - CA (CP) │ │ - Graph │ │ │ │ - AP │ └─────────────┘ └──────────────────┘ └────────┬────────┘ │ POLYGLOT PERSISTENCE Αποθήκευση δεδομένων client-side vs. server-side Μερικές φορές η εφαρμογή χρησιμοποιεί την αποθήκευση της κινητής συσκευής στην οποία είναι εγκατεστημένη. για παράδειγμα, τα μηνύματα WhatsApp αποθηκεύονται στην τοπική αποθήκευση του smartphone σας, με προαιρετική δημιουργία αντιγράφων ασφαλείας στο cloud. Μερικές φορές, όλα τα δεδομένα αποθηκεύονται στους διακομιστές. για παράδειγμα, όλα τα μηνύματα στο Facebook Messenger αποθηκεύονται στους διακομιστές του Facebook. Πριν ξεκινήσετε τον κύκλο ανάπτυξης, πρέπει να καθορίσετε με σαφήνεια ποια στοιχεία θα χρησιμοποιούν τους πόρους του διακομιστή και ποια θα χρησιμοποιούν τους τοπικούς πόρους της συσκευής. ╔═══════════════════════════════════════════════════╗ ║ CLIENT-SIDE vs SERVER-SIDE STORAGE ║ ╚═══════════════════════════════════════════════════╝ CLIENT-SIDE SERVER-SIDE ┌──────────────┐ ┌──────────────┐ │ Mobile │ │ Server │ │ Device │ │ Cluster │ ├──────────────┤ ├──────────────┤ │ ┌──────────┐ │ │ ┌──────────┐ │ │ │ WhatsApp │ │ │ │ Facebook │ │ │ │ Messages │ │ │ │Messenger │ │ │ │ (Local) │ │ │ │ Messages │ │ │ └──────────┘ │ │ └──────────┘ │ │ │ │ │ │ + Optional │ │ + Backup │ │ Cloud │ │ + Sync │ │ Backup │ │ + Access │ └──────────────┘ └──────────────┘ Βελτιστοποιημένες δομές δεδομένων Κάθε γραμμή κώδικα που γράφετε φορολογεί τον διακομιστή.Όσο περισσότερο ο φόρος, τόσο περισσότερο πρέπει να πληρώσετε για να το διατηρήσετε.Αυτός είναι ο λόγος για τον οποίο είναι καλή πρακτική να γράφετε βελτιστοποιημένο κώδικα λογισμικού και να χρησιμοποιείτε δομές δεδομένων που έχουν χαμηλότερες περιπλοκές χρόνου και χώρου. ╔═════════════════════════════════════╗ ║ OPTIMIZED DATA STRUCTURES ║ ╚═════════════════════════════════════╝ Data Structure Complexity O(1) ───────── Best (Hash Table) O(log n) ────── Good (Binary Tree) O(n) ───────── Acceptable (Array) O(n²) ───────── Poor (Nested Loops) O(2ⁿ) ───────── Worst (Exponential) ┌─────────────────────────────┐ │ Choose Lower Complexity │ │ = Less Server Tax │ │ = Lower Costs │ └─────────────────────────────┘ Ρυθμίσεις απορρήτου Οι χρήστες της εφαρμογής σας πρέπει να έχουν επιλογές για να προστατεύσουν τον εαυτό τους στο διαδίκτυο. Πρέπει να έχετε καλές επιλογές απορρήτου. Για παράδειγμα, στο WhatsApp, μπορείτε να κρύψετε τη φωτογραφία προφίλ σας, να διαβάσετε τις αποδείξεις και να δείτε τελευταία. +-----------------------------------------+ | PRIVACY SETTINGS | +-----------------------------------------+ +-----------------------------------------+ | User Privacy Panel | +-----------------------------------------+ | [ ] Show Profile Photo | | [X] Hide Last Seen | | [X] Hide Read Receipts | | [ ] Show Online Status | | [X] Block User | | | | [Save Settings] | +-----------------------------------------+ Συμμόρφωση Η εφαρμογή σας πρέπει να συμμορφώνεται με τους απαιτούμενους κανονισμούς. για παράδειγμα: If your application handles Protected Health Information (PHI) for covered entities, it should be HIPAA compliant. If your application is being launched in the EU, it should be GDPR compliant. ╔═════════════════════════════════════╗ ║ COMPLIANCE REQUIREMENTS ║ ╚═════════════════════════════════════╝ ┌──────────────────────────────────┐ │ Your Application │ └────────────┬─────────────────────┘ │ ┌──────┴──────┐ │ │ ┌─────▼─────┐ ┌────▼──────┐ │ HIPAA │ │ GDPR │ │Compliance │ │Compliance │ ├───────────┤ ├───────────┤ │ Medical │ │ EU │ │ PHI │ │ Privacy │ │ Protected │ │ Rules │ └───────────┘ └───────────┘ Πτυχές Ασφάλειας Ενώ η ασφάλεια είναι ένα πολύ ευρύ θέμα, στην αρχική σας ανάλυση πρέπει να εξετάσετε την προστασία από spam και DDoS. Πρέπει να έχετε τη σωστή δομή IAM και ισχυρές πολιτικές κωδικών πρόσβασης. ╔═════════════════════════════════════╗ ║ SECURITY LAYERS ║ ╚═════════════════════════════════════╝ ┌───────────────────────────────────┐ │ Security Layers │ ├───────────────────────────────────┤ │ Layer 5: 2FA Authentication │ ├───────────────────────────────────┤ │ Layer 4: IAM & Access Control │ ├───────────────────────────────────┤ │ Layer 3: DDoS Protection │ ├───────────────────────────────────┤ │ Layer 2: Spam Filtering │ ├───────────────────────────────────┤ │ Layer 1: Password Policy │ └───────────────────────────────────┘ Υπηρεσίες που διατίθενται στην περιοχή ανάπτυξης Όπως υποδηλώνει ο τίτλος, όλες οι υπηρεσίες που εξετάζετε πρέπει να είναι διαθέσιμες στη γεωγραφική περιοχή όπου σκοπεύετε να ξεκινήσετε την εφαρμογή σας. +---------------------------------------+ | GEOGRAPHICAL SERVICE AVAILABILITY | +---------------------------------------+ GLOBAL SERVICE MAP +--------------+ +--------------+ | USA | | China | +--------------+ +--------------+ | [+] Facebook | | [-] Facebook | | [+] Google | | [-] Google | | [+] AWS | | [+] Alibaba | | [+] WhatsApp | | [+] WeChat | +--------------+ +--------------+ Check Service Availability Before Launch! Ανάλυση κόστους Χωρίς να θέτετε σε κίνδυνο την αποδοτικότητα και τις επιδόσεις, θα πρέπει να μειώσετε το κόστος όσο το δυνατόν περισσότερο. ╔═════════════════════════════════════╗ ║ COST OPTIMIZATION ║ ╚═════════════════════════════════════╝ ┌────────────────────────────────────┐ │ Cost Optimization │ ├────────────────────────────────────┤ │ │ │ Open Source >>> Proprietary │ │ (Lower Cost) (Higher Cost) │ │ │ │ Serverless >>> Always-On │ │ (Pay per use) (Fixed Cost) │ │ │ │ Cache >>> DB Query │ │ (Expensive) (Cheaper) │ │ │ └────────────────────────────────────┘ Balance Cost vs Performance On-Prem / Cloud / Υβριδικό Αποφασίστε αν τα δεδομένα σας θα είναι on-prem, εντελώς στο cloud, ή εν μέρει cloud και εν μέρει on-prem (υβριδικό). ╔═════════════════════════════════════╗ ║ DEPLOYMENT OPTIONS ║ ╚═════════════════════════════════════╝ ┌──────────────────────────────────────┐ │ Deployment Options │ └───────────┬──────────────────────────┘ │ ┌───────┼───────┐ │ │ │ ┌───▼───┐ ┌─▼────┐ ┌▼──────┐ │On-Prem│ │Cloud │ │Hybrid │ ├───────┤ ├──────┤ ├───────┤ │Local │ │ AWS │ │On-Prem│ │Servers│ │Azure │ │ + │ │ Data │ │ GCP │ │ Cloud │ │Center │ │ │ │ Mix │ └───────┘ └──────┘ └───────┘ │ ┌───▼────┐ │ VPC │ └────────┘ Οριζόντια κλιμάκωση / Vertical Scaling & Load Balancers Στην οριζόντια κλιμάκωση, τοποθετείτε αντίγραφα του τρέχοντος διακομιστή DB / διακομιστή εφαρμογών και χρησιμοποιήστε έναν εξισορροπητή φόρτωσης για να εξισορροπήσετε την κίνηση μεταξύ αυτών των περιπτώσεων. Στην κατακόρυφη κλιμάκωση, βελτιώνετε τη διαμόρφωση του συστήματος του παραδείγματος. Υπάρχει κάποιο όριο σε αυτό που μπορείτε να βελτιώσετε. Υπάρχουν και άλλες εκτιμήσεις - για παράδειγμα, αν αυξήσετε τον υπολογιστή, θα πρέπει να αυξήσετε τη μνήμη RAM ανάλογα. Οι ισοσκελιστές φορτίου χρησιμοποιούνται για την εξισορρόπηση της κυκλοφορίας μεταξύ διαφόρων περιπτώσεων. οι ισοσκελιστές φορτίου συμβάλλουν στη μείωση των χρόνων διακοπής λειτουργίας του συστήματος. +-------------------------------------------------------------+ | HORIZONTAL & VERTICAL SCALING WITH LOAD BALANCERS | +-------------------------------------------------------------+ HORIZONTAL SCALING VERTICAL SCALING +---------------+ +---------------+ | Load Balancer | | Upgrade | +-------+-------+ | CPU + RAM | | +-------+-------+ | | +-------------+-------------+ | | | | | v v v (and v) v +---+ +---+ +---+ +---------------+ |DB1| |DB2| |DB3|... | Powerful | +---+ +---+ +---+ | Server | +---------------+ Add more servers Improve single server Απόκτηση πελατών και διατήρηση πελατών Ενσωματώστε αναλύσεις όπως η ανάλυση λωρίδας και οι δοκιμές A/B για να βελτιώσετε τη βάση πελατών σας. ╔═════════════════════════════════════╗ ║ CUSTOMER ACQUISITION & RETENTION ║ ╚═════════════════════════════════════╝ ┌─────────────────────────────────────┐ │ Analytics Funnel │ ├─────────────────────────────────────┤ │ │ │ 1000 Users ▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓ │ │ │ │ │ 500 Signups ▓▓▓▓▓▓▓▓▓ │ │ │ │ │ 200 Active ▓▓▓▓ │ │ │ │ │ 100 Paid ▓▓ │ │ │ ├─────────────────────────────────────┤ │ A/B Testing │ │ ┌─────────┐ ┌─────────┐ │ │ │Version A│ │Version B│ │ │ │ 50% │ │ 50% │ │ │ └────┬────┘ └─────┬───┘ │ │ └──────┬────────┘ │ │ Compare │ └─────────────────────────────────────┘ Σύνοψη : ================================ SYSTEM DESIGN IN A NUTSHELL 17 Core Concepts ================================ START HERE | ↓ 1. UX DESIGN & COMPONENTS → Design UI elements → Profile, messages, feeds | ↓ 2. CLASSES & SUBCLASSES → Define objects → User profiles with attributes | ↓ 3. DESIGN PATTERNS → Publisher-Subscriber → For news feeds | ↓ 4. INFRASTRUCTURE STACK → CDN for static content → Serverless functions → API Gateway → Cache strategy | ↓ 5. CONSISTENCY MODELS → Eventual (NoSQL) → Transactional (SQL) | ↓ 6. EVENT HANDLING → Request to response → Data packet routes | ↓ 7. DATABASE STRATEGY → SQL: Structured data → NoSQL: Key-value, docs → CAP Theorem considerations → Polyglot Persistence | ↓ 8. DATA STORAGE → Client-side (local) → Server-side (cloud) → Hybrid approach | ↓ 9. OPTIMIZED DATA STRUCTURES → Lower time complexity → Lower space complexity → Reduce server tax | ↓ 10. PRIVACY SETTINGS → Hide profile info → Block users → Read receipts control | ↓ 11. COMPLIANCE → HIPAA for medical PHI → GDPR for EU users | ↓ 12. SECURITY LAYERS → DDoS protection → IAM structure → 2FA authentication → Password policies → Spam filtering | ↓ 13. GEOGRAPHICAL SERVICES → Check availability → Regional restrictions → Example: Facebook in China | ↓ 14. COST OPTIMIZATION → Open source frameworks → Serverless options → Balance cost vs performance | ↓ 15. DEPLOYMENT OPTIONS → On-Premises → Cloud (AWS/Azure/GCP) → Hybrid approach → VPC considerations | ↓ 16. SCALING STRATEGIES → Horizontal: Add replicas → Vertical: Upgrade config → Load balancers → Mix both approaches | ↓ 17. CUSTOMER ANALYTICS → Funnel analytics → A/B testing → Acquisition & retention ================================ KEY TAKEAWAYS ================================ ★ 30,000 ft view first ★ Design before coding ★ Consider all 17 aspects ★ Balance trade-offs ★ Optimize for scale ★ Security & compliance ★ Cost-effective choices ================================ Αυτό το πλαίσιο θα σας βοηθήσει επίσης να ξεκαθαρίσετε ερωτήσεις συνέντευξης σχεδιασμού συστήματος εισόδου σε οποιοδήποτε κορυφαίο MNC. Όταν άρχισα να γράφω αυτό το άρθρο, είχα πολύ περισσότερα στο μυαλό μου. έπρεπε να κόψω το περιεχόμενο καθώς πολλές από τις έννοιες που αναφέρονται εδώ μπορούν να εξηγηθούν σε ξεχωριστά άρθρα. Ευχαριστώ για την ανάγνωση.Μείνετε συντονισμένοι. Εάν έχετε οποιεσδήποτε ερωτήσεις, παρακαλούμε μη διστάσετε να μου στείλετε email. Μπορείτε επίσης να επικοινωνήσετε μαζί μου μέσω του Linkedin. Μπορείτε επίσης να με ακολουθήσετε στο X email email Λίντενιν Λίντενιν X X